Recording method of stream data and data structure thereof

ABSTRACT

An information medium which has a data area for recording stream data (SOB) using stream packets each of which includes an application packet area, and a management area for recording management information that pertains to the stream data (SOB) is used. The stream data (SOB) are distributed and recorded in the application packet areas in a plurality of the stream PES packets. When the start portion of the application packet area included in the first stream PES packet in the stream data (SOB) does not match the first byte of a time stamp appended to the first application packet in the application packet area, then information is recorded so that they match.

BACKGROUND OF THE INVENTION

[0001] The present invention relates to a method of recording video datasent in digital broadcast or the like or stream data sent with a packetstructure, a data structure of stream data suitable for this recordingmethod, and information medium on which information is recorded usingthis data structure.

[0002] In recent years, TV broadcast has come into the era of digitalbroadcast. Accordingly, an apparatus for saving digital data of digitalTV broadcast as they are irrespective of their contents, i.e., aso-called streamer, has been demanded.

[0003] The current digital TV broadcast uses an MPEG transport stream.In the future, an MPEG transport stream will be used as a standard onein the field of digital broadcast using moving picture.

[0004] In such digital broadcast, the contents (mainly, videoinformation) to be broadcasted are time-divided into groups of data eachhaving a predetermined size (e.g., 188 bytes) called transport packets,and broadcast data is sent in units of transport packets.

[0005] As a streamer for recording digital broadcast data, a homedigital VCR such as D-VHS (digital VHS) or the like is currentlycommercially available. A streamer using D-VHS directly records abroadcasted bitstream on a tape. For this reason, a plurality ofprograms are multiplexed and recorded on a video tape.

[0006] Upon playback, all data are output from the VCR to a set-top box(digital TV reception apparatus; to be abbreviated as an STBhereinafter) when they are played back either from the beginning or themiddle of the tape. In this STB, a desired program is selected from theoutput data by user operation or the like. The selected programinformation is transferred from the STB to a digital TV receiver, and isplayed back (playback of video plus audio and the like).

[0007] Since this D-VHS streamer uses a tape as a recording medium, itcannot attain quick random access, and it is difficult to quickly jumpto a desired position of a required program so as to play it back.

[0008] As a promising candidate that can combat such shortcoming(difficulty of random access) of the tape, a streamer that uses alarge-size disc medium such as a DVD-RAM or the like has been proposed.In this case, management data must be inevitably recorded together withbroadcast data in consideration of random access, special playback, andthe like.

[0009] When a DVD-RAM disc is used as an information storage medium,data are recorded in units of 2,048-byte sectors. On the other hand,digital TV broadcast adopts an MPEG transport stream, and stream dataeach of which stores video information are sent in units of 188-bytetransport packets as minimum units of the transport stream. The size ofthis transport packet differs depending on digital TV broadcast stationsand, for example, a given digital TV broadcast station sends data inunits of 130 bytes. When such received transport packets are recorded inunits of sectors on an information storage medium such as a DVD-RAM discor the like as they are, the following problems are posed. That is:

[0010] 1. Since 2,048 bytes as the sector size are not an integermultiple of the transport packet size (e.g., 188 bytes), a recordingmethod of transport packets in a sector poses a problem.

[0011] More specifically, when transport packets are allocated in agiven sector in turn from the first one, and the remaining area formedin this sector is handled as a padding area, a large number of wastefulpadding areas are generated in units of sectors. For this reason, thestream data size that can be recorded on the information storage mediumdecreases by the padding areas in units of sectors. As a result, thepractical recording capacity of the information storage mediumdecreases.

[0012] 2. Stream data that have been video-compressed according to theMPEG format must be decoded by a decoder after they are played back fromthe information storage medium. In this case, the time interval betweenneighboring transport packets to be transferred to the decoder must holdthat immediately after they were received from a digital TV broadcaststation. For this reason, time interval information of each transportpacket upon being transferred to the decoder is required.

[0013] 3. Since transport packets recorded on the information storagemedium have no identification information for identifying individualtransport packets, there is no means for designating a specifictransport packet upon search or edit.

[0014] 4. When a DVD-RAM disc is used as an information storage medium,since data are recorded in units of 2,048-byte sectors, it is difficultto implement a partial erase process in units of transport packets.

[0015] 5. Since stream data sent in digital TV broadcast have beenvideo-compressed in accordance with the MPEG format, decoding must bestarted from an I-picture position. Therefore, a partial erase processat a specific video position must be done to have an I-picture startposition at the head position of the data as a boundary position inpractice. However, in information obtained by merely recording transportpackets in turn in sectors, it is difficult to implement a partial eraseprocess using the I-picture start position as the boundary position.

[0016] It is an object of the present invention to provide a recordingmethod that can efficiently record stream data.

[0017] It is another object of the present invention to provide a datastructure that can efficiently manage stream data.

BRIEF SUMMARY OF THE INVENTION

[0018] In order to achieve the above object, a recording methodaccording to the present invention uses an information medium (201)which has a data area (STREAM.VRO/SR_TRANS.SRO) for recording streamdata (SOB) using stream PES packets each of which includes anapplication packet area that includes one or more application packetswith time stamps (ATS), and a management area (STREAM.IFO/SR_MANGR.IFO)for recording management information (STRI) that pertains to the streamdata (SOB).

[0019] The stream data (SOB) are distributed and recorded in theapplication packet areas of a plurality of stream PES packets (cf. ST10in FIG. 12). When the start portion of the application packet areaincluded in the first stream PES packet in the stream data (SOB) doesnot match the first byte of a time stamp (ATS) appended to the firstapplication packet in the application packet area, information recordingis done so that they match (cf. ST16 in FIG. 12).

[0020] In another recording method according to the present invention,the stream data (SOB) are distributed and recorded in the applicationpacket areas of a plurality of stream PES packets (cf. ST10 in FIG. 12).When a blank portion is formed at the end of the application packetarea, a stuffing area (cf. stuffing area in FIG. 5(h) or padding area 37in FIG. 19(j)) formed of a predetermined number of bytes (without anytime stamp) is provided or assured in the blank portion (cf. some ofprocesses in ST22 of FIG. 12).

[0021] In still another recording method according to the presentinvention, as a result of distributing and recording the stream data(SOB) in the application packet areas of a plurality of stream packs(cf. ST10 in FIG. 12), when a blank portion for one stream pack or more(cf. area of sector No. n in FIG. 6(e)) is formed between the end of thelast stream pack that actually contains stream data, and the end of anarea that records the stream data, stuffing packets (FIG. 6(i) and (j))that fill the blank portion are recorded (cf. ST20 in FIG. 12).

[0022] In still another recording method according to the presentinvention, the stream data (SOB) is formed by a plurality of data units(SOBU#α, . . . , SOBU#λ in FIG. 8 (a)), and each data unit is formed byone or more data packets (TP/AP in FIG. 8(b)) each of which recordspredetermined time stamp (TMS) information.

[0023] At least a time difference value (rounded value in FIG. 8(c) and(d)) corresponding to the difference between the first time stamp (TMS 1a) recorded in the first data unit (SOBU#α) and the second time stamp(TMS 33 a) recorded in the second data unit (SOBU#β) of a plurality ofthe data units (SOBU#α, . . . , SOBU#λ) is recorded in the managementarea (STREAM.IFO/SR_MANGR.IFO) (cf. some of processes in ST24 in FIG.12).

[0024] In still another recording method according to the presentinvention, one or more pieces of cell information (cf. FIG. 18) arerecorded in the stream data (SOB), and information (PGCI in FIG. 3(f) orFIG. 13) of a program chain (PGC) that describes a set of one or morecells is recorded in the management area (STREAM.IFO/SR_MANGR.IFO).

[0025] Information (SC_EPI) of an entry point (EP), which can be used asa marker of a skip position upon partially skipping recorded contents ofthe stream data (SOB) in playback, is recorded in the managementinformation (STRI) (cf. some of processes in ST24 in FIG. 12).

[0026] In order to achieve the other object, a data structure accordingto the present invention has a data area (STREAM.VRO/SR_TRANS.SRO) forrecording stream data (SOB or SOBU) using predetermined data recordingunits (transport packets or application packets), and a management area(STREAM.IFO/SR_MANGR.IFO) for recording management information (STRI)that pertains to the stream data.

[0027] A plurality of stream packs each of which contains one or moredata recording units (application packets) with time stamps (ATS) areused, and the stream data are distributed to a plurality of the streampacks. Each stream pack contains a pack header and a stream PES packet.

[0028] The start portion of an application packet area included in thefirst stream PES packet in the stream data (SOB) matches the start byteof the time stamp (ATS) appended to the first data recording unit(application packet) in the application packet area.

[0029] Note that the stream PES packet may include a stuffing byte of avariable length including zero byte length, and an application packetarea including one or more data recording units (application packets)with time stamps (ATS).

[0030] In another data structure according to the present invention,when a blank portion is formed at the end of the application packetarea, a stuffing area (stuffing area in FIG. 5(h) or padding area 37 inFIG. 19(j)) formed of (or consisting of) a predetermined number of bytes(without any time stamp) is provided or assured in the blank portion.

[0031] In still another data structure according to the presentinvention, when a blank for one stream pack or more is formed betweenthe end of the last stream pack that actually contains stream data(SOB), and the end of an area that records the stream data (SOB),stuffing packets that fill the blank portion are recorded as paddingdata.

[0032] In still another data structure according to the presentinvention, the stream data (SOB) includes a plurality of data units(SOBU#α, . . . , SOBU#λ in FIG. 8(a)), and each of the data units(SOBU#, . . . , SOBU#λ) includes one or more data packets (TP/AP in FIG.8(b)) each of which records time stamp (TMS) information.

[0033] A time difference value (rounded value in FIG. 8(c) and (d))corresponding to the difference between the first time stamp (TMS 1 a)recorded in the first data unit (SOBU#α) and the second time stamp (TMS33 a) recorded in the second data unit (SOBU#λ) of a plurality of thedata units (SOBU#α, . . . , SOBU#λ) is recorded in the management area(STREAM.IFO/SR_MANGR.IFO).

[0034] In still another data structure according to the presentinvention, one or more pieces of cell information (cf. FIG. 18) arerecorded in the stream data (SOB), and information (PGCI in FIG. 3(f) orFIG. 13) of a program chain (PGC) that describes a set of one or morecells is recorded in the management area (STREAM.IFO/SR_MANGR.IFO).

[0035] The management information (STRI) stores information (SC_EPI) ofan entry point (EP) which can be used as a marker of a skip positionupon partially skipping recorded contents of the stream data (SOB) inplayback.

[0036] Additional objects and advantages of the invention will be setforth in the description which follows, and in part will be obvious fromthe description, or may be learned by practice of the invention. Theobjects and advantages of the invention may be realized and obtained bymeans of the instrumentalities and combinations particularly pointed outhereinafter.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

[0037] The accompanying drawings, which are incorporated in andconstitute a part of the specification, illustrate presently preferredembodiments of the invention, and together with the general descriptiongiven above and the detailed description of the preferred embodimentsgiven below, serve to explain the principles of the invention.

[0038]FIG. 1 is a view for explaining the data structure of stream dataaccording to an embodiment of the present invention;

[0039]FIG. 2 is a view for explaining the directory structure of datafiles according to an embodiment of the present invention;

[0040]FIG. 3 is a view for explaining the recorded data structure(especially, the structure of management information) on an informationmedium (recordable/reproducible DVD disc) according to an embodiment ofthe present invention;

[0041]FIG. 4 is a view for explaining the relationship among streamobjects (SOB), cells, program chains (PGC), and the like in the presentinvention;

[0042]FIG. 5 is a view for explaining the relationship among the videodata transfer formats in digital broadcast, IEEE1394, and a streamer;

[0043]FIG. 6 is a view for explaining the sector structure that storesdata of a stream object;

[0044]FIG. 7 is a view for explaining the relationship between the videoinformation compression method in MPEG and transport packets;

[0045]FIG. 8 is a view for explaining the method of setting time mapinformation shown in FIG. 1, etc.;

[0046]FIG. 9 is a view for explaining changes in stream objectinformation and original cell information before and after the recordedstream object is partially erased;

[0047]FIG. 10 is a view for explaining the data structure of a streampack shown in FIG. 5, etc.;

[0048]FIG. 11 is a block diagram for explaining the arrangement of astream data recording/playback system (optical disc device/streamer, STBunit) according to an embodiment of the present invention;

[0049]FIG. 12 is a flow chart for explaining the processes of alignmentbetween an application packet and stream object and a padding process atthe end of a stream object when information recording of a bitstream isdone by the system shown in FIG. 11;

[0050]FIG. 13 is a view for explaining the internal data structure ofmanagement information (STREAM.IFO in FIG. 2 or 3) of the streamer;

[0051]FIG. 14 is a view for explaining the internal data structure ofPGC information (ORG_PGCI/UD_PGCIT in FIG. 3 or PGCI#i in FIG. 13);

[0052]FIG. 15 is a view for explaining the internal data structure of astream file information table (SFIT);

[0053]FIG. 16 is a view exemplifying the correspondence between anaccess unit start map (AUSM) and stream object unit (SOBU);

[0054]FIG. 17 is a view exemplifying the correspondence between anaccess unit start map (AUSM) and access unit end map (AUEM), and streamobject unit (SOBU);

[0055]FIG. 18 is a view for explaining the relationship between cellsdesignated by an original or user-defined PGC and SOBUs corresponding tothese cells via time map information; and

[0056]FIG. 19 is a view for explaining the data structure of stream dataaccording to another embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0057] A recording method of stream data, its data structure, and so on,according to an embodiment of the present invention will be describedhereinafter with reference to the accompanying drawings.

[0058]FIG. 1 is a view for explaining the data structure of stream dataaccording to an embodiment of the present invention.

[0059] Stream data are recorded on an information storage medium to becombined as a stream object in correspondence with the contents of videoinformation or single video recording contents in stream data.

[0060]FIG. 1(h) exemplifies a stream object recorded on an informationmedium such as a DVD-RAM disc or the like. FIG. 1(h) shows the last partof stream object #A 298 and stream object #B 299 recorded after thatstream object.

[0061] When such stream data are recorded on the DVD-RAM disc or thelike, the data are recorded using 2,048-byte sectors as minimum units,as shown in FIG. 1(d). Each sector is divided into recording areas ofpack headers (or packet headers) 11 to 15 and data areas for recordingstream data, as shown in FIG. 1(c) and (e).

[0062] Each data area is packed in turn with time stamps and transportpackets, as shown in FIG. 1(f) and (g). Such packing can be done asfollows. That is:

[0063] 1. Time stamps and transport packets are sequentially recordedtogether at a location other than pack headers 11 to 15 in a sector, andwhen the division (or cutting portion) of a time stamp or that of streamdata recorded in units of transport packets is different from a sectorboundary position, either the time stamp or transport packet isallocated and recorded to a position being across to the neighboring (oradjacent) sector.

[0064] More specifically, when time stamps and transport packets arepacked in turn in data area No. 1 in FIG. 1(g), a portion of transportpacket 1 k cannot be stored in and overflows from data area No. 1. Theportion of this transport packet 1k, which overflows from data area No.1 is successively recorded at the head position of data area No. 2 inthe next sector No. 2.

[0065] 2. A group of single video recording contents done by the user orthe like or a group of identical contents such as a single program orthe like is defined as a stream object. When the last transport packetposition of the stream object recorded on the information storage mediumis different from a sector boundary position, an area after that lasttransport packet position is set as a padding area as long as thecorresponding sector has a remaining area.

[0066] More specifically, in the example shown in FIG. 1(k), videorecording comes to an end at transport packet 321 a, which is apractical last position of stream object #B 299. In this case, when thistransport packet 321 a is allocated in the middle of data area No. 321in FIG. 1(j), the remaining area after packet 321 a is set as paddingarea 21.

[0067] Using such data structure, a packet having a size larger than thesector size can be efficiently recorded.

[0068]FIG. 1 also shows the data structure that pertains to time mapinformation. The contents of data in time map information 252 will bedescribed below using FIG. 1.

[0069] As exemplified in FIG. 1(h) and (i), stream object (SOB) #B•299consists of a plurality of stream blocks (SOBUs) #α to #γ.

[0070] In the example shown in FIG. 1(h) and (i), the data size of eachof stream blocks (SOBUs) #α to #γ that form SOB#B•299 is equal to twoECC blocks, i.e., a size for 32 sectors. That is, each of first streamblock sizes 261 to 264 (FIG. 1(l)) in time map information (FIG. 1(m))is equal to 32 sectors (64k bites).

[0071] First stream block (SOBU) #α (FIG. 1(i)) in SOB#B•299 (FIG. 1(h))has sector No. 1 (FIG. 1(d)) at its head position, and time stamp la(FIG. 1(g) and (k)) is recorded at the head position of data area No. 1(FIG. 1(e), (f), and (j)) included in sector No. 1.

[0072] Succeeding stream block (SOBU) #β (FIG. 1(i)) of SOB#B•299 (FIG.1(h)) has data area No. 33 (FIG. 1(j)), which records transport packet33 a (FIG. 1(k)) with time stamp 33 a.

[0073] As shown in FIG. 1(k), the time stamp value [0] of the firststream data (transport packet 1 a) of stream block (SOBU) #α is timestamp 1 a, and the time stamp value [28] of stream data (transportpacket 33 a) in the next stream block (SOBU) #β is time stamp 33 a.

[0074] The value [30] of first stream block time difference 266 in FIG.1(l) is given by rounding the difference value ([28]−[0]) between timestamps 33 a and la to retain a predetermined effective number of digits(in this case, one effective digit) (by increasing the last retaineddigit by 1) ([28]−[0]≈[30]).

[0075] Note that time map information 252 in FIG. 1(m) may be handled asthe one including access data unit AUD in stream object information SOBIwhich will be described later with reference to FIG. 15. Withinformation (access unit start map AUSM and the like) included in thisAUD, an SOBU that includes information to be accessed (requiredI-picture information or the like) can be specified.

[0076] In the format shown in FIG. 1, the sector number of the firstsector of stream object #B 299 is set at 1, and the sector number isincremented in turn. The sector number matches the data area number, andthe time stamp number and transport packet number are set incorrespondence with these numbers. That is, the first pair of time stampand transport packet allocated in a data area in the 33rd sector are setto have the number “33a ”, and the numbers of the subsequent pairs inthat data area are set to be “33b”, “33c”, . . . Note that the number ofthe time stamp or transport packet such as transport packet 32 j or 320k which overflows from the immediately preceding data area and isrecorded to a position in the next data area is indicated incorrespondence with the immediately preceding data area number. Also,the contents of brackets [] in FIG. 1(k) exemplify the actual values oftime stamps.

[0077] As shown in FIG. 1(a) to (c), as intra-sector common information41 in information in pack headers (or packet headers) 11 to 15, packheader size 51, time stamp size 52, and transport packet size 53 aredescribed.

[0078] Taking sector No. 1 in FIG. 1(d) as an example, first time stampvalue 54 in a sector in search information 42 in FIG. 1(b) means thevalue of time stamp 1 a [=0] in FIG. 1(k). On the other hand, last timestamp value 55 in a sector in search information 42 means the value oftime stamp 1 k (not shown).

[0079] Many dictionaries contain footnotes or the first and last wordsof individual pages at the header positions in these pages so as tofacilitate a search. Likewise, the two pieces of information (first andlast time stamp values 54 and 55 shown in FIG. 1(a)) facilitate a searchof stream data.

[0080] Since a single time stamp or transport packet can be allocatedacross neighboring sectors, when an independent access is made in unitsof sectors, the first time stamp position information is required. Firstaccess point 56 shown in FIG. 1(a) means the number of bits counted froma position immediately after the packet header to the first time stampposition. However, this embodiment is not limited to such specificinformation. For example, the number of bits to the first transportpacket head position may be provided as information (equivalent to firstaccess point 56).

[0081] In this embodiment, since a value larger than the data area sizecan be designated as the value of first access point 56, the time stamphead position of a packet having a size larger than the sector size canbe designated.

[0082] For example, a case will be examined below wherein in the datastructure shown in FIG. 1(d) to (g), a single packet is recorded acrosssectors No. 1 and No. 2, a time stamp for that packet is recorded at thefirst position in a data area of sector No. 1, and a time stamp for thenext packet is allocated at the T-th bit position in a data area insector No. 2.

[0083] In this case, the value of first access point 56 of sector No. 1is “the data area size of sector No. 1+T), and the value of the firstaccess point of sector No. 2 is “T”.

[0084] Since a value larger than the data area size of sector No. 1 isset as the value of first access point 56 of sector No. 1, it indicatesthat the position of a time stamp corresponding to a packet that followsthe packet recorded in sector No. 1 is present in the next sector orsubsequent sector.

[0085] When partial erase (see FIG. 9) is done in units of sectors, lastposition information 57 (FIG. 1(a)) of a substantially effective pair oftime stamp and transport packet which do not run to a position in thenext sector is required.

[0086] In this embodiment, the number of pairs of time stamps andtransport packets which are recorded in a complete form (do not run toother sectors) is described. However, this embodiment is not limited tosuch specific information, and information of, e.g., the last positionaddress may be recorded (as last position information 57).

[0087] As shown in FIG. 1(a) and (b), bitmap information 43 thatpertains to each transport packet includes I-picture position flag 58,picture head position flag 59, and cipher information 60. I-pictureposition flag 58 and picture head position flag 59 in FIG. 1(a) can begenerated using information of random access indicator 303 and payloadunit start indicator 301 which will be described later with reference toFIG. 5. Cipher information 60 records information used in copyprotection as needed.

[0088] Based on intra-sector common information 41 and searchinformation 42 in FIG. 1(b), the number of transport packets in a sectorof interest can be detected. One bit is assigned to each of thesetransport packets in the layout order, and a flag “1” can be set for atransport packet that clears the above condition. Bitmap information 43which pertains to individual transport packets set with these flags isrecorded in a pack header, as shown in FIG. 1(b) and (c).

[0089] In digital broadcast, video information compressed according tothe MPEG2 format is transferred. Digital broadcast adopts amulti-program compatible multiplexing/demultiplexing scheme called atransport stream, as shown in FIG. 5(c), and one transport packet b 322often has a size of 188 bytes (or 183 bytes).

[0090] As described above, one sector size is 2,048 bytes, and each dataarea can record approximately 10 transport packets for digital broadcasteven after various header sizes are subtracted. By contrast, in adigital communication network such as ISDN or the like, a long packethaving a packet size as large as 4,096 bytes is often transferred.

[0091] Using the data structure in FIG. 1, one packet can be recordedacross a plurality of data areas, so that a packet with a large packetsize such as a long packet can be recorded. All packets, i.e., transportpackets for digital broadcast, a long packet for digital communications,and the like can be recorded in a stream block (SOBU in FIG. 1(i))without any fractions independently of their packet sizes.

[0092]FIG. 2 is a view for explaining the directory structure of datafiles according to an embodiment of the present invention. The contents(file structure) of information recorded on the information storagemedium according to an embodiment of the present invention will beexplained below.

[0093] Each information recorded on an information storage medium suchas a DVD-RAM disc or the like has a hierarchical file structure. Videoinformation and stream data information to be explained in thisembodiment are stored in subdirectory 101 named DVD_RTR directory (orDVD_RTAV) 102.

[0094] DVD_RTR (DVD_RTAV) directory 102 stores data file 103 having thefollowing contents. More specifically, as a group of managementinformation (navigation data),

[0095] RTR.IFO (VR_MANGR.IFO) 104, STREAM.IFO

[0096] (SR_MANGR.IFO/SR_MANGR.BUP) 105, and

[0097] SR_PRIVT.DAT/SR_PRIVT.BUP 105 a are stored.

[0098] As a data main body (contents information), STREAM.VRO(SR_TRANS.SRO) 106, RTR_MOV.VRO (VR_MOVIE.VRO) 107, RTR_STO.VRO (orVR_STILL.VRO) 108, and RTR_RTR STA.VRO (or VR_AUDIO.VRO) 109 are stored.

[0099] Root directory 100 as an upper layer of subdirectory 101including data file 103 can be provided with subdirectory 110 forstoring other kinds of information. This subdirectory includes, as itscontents, video title set VIDEO_TS 111 that stores video programs, audiotitle set AUDIO_TS 112 that stores audio programs, subdirectory 113 forsaving computer data and the like.

[0100] Data which is transmitted on a wired or wireless datacommunication path in the form of a packet structure and is recorded onan information storage medium while holding the packet structure iscalled “stream data”.

[0101] The stream data themselves are recorded together with file nameSTREAM.VRO (or SR_TRANS.SRO) 106. A file that records managementinformation of the stream data is STREAM.IFO (or SR_MANGR.IFO and itsbackup file SR_MANGR.BUP) 105.

[0102] A file that records analog video information which is used in aVCR (VTR) or conventional TV and is digitally compressed based on MPEG2is RTR_MOV.VRO (or VR_MOVIE.VRO) 107, a file that collects still pictureinformation including postrecorded audio, background audio, or the likeis RTR_STO.VRO (or VR_STILL.VRO) 108, and its postrecorded audioinformation file is RTR_STA.VRO (or VR_AUDIO.VRO) 109.

[0103]FIG. 3 is a view for explaining the recorded data structure(especially, the structure of management information) on an informationmedium (recordable/reproducible DVD disc) according to an embodiment ofthe present invention.

[0104] In an area sandwiched between the ends of inner circumferentialdirection 202 and outer circumferential direction 203 of informationstorage medium 201 shown in FIG. 3(a), lead-in area 204, volume & filestructure information 206 that records file system information, dataarea 207, and lead-out area 205 are present, as shown in FIG. 3(b).Lead-in area 204 is made up of an emboss zone and rewritable data zone,and lead-out area 205 is made up of a rewritable data zone. Data area207 is also made up of a rewritable data zone.

[0105] Data area 207 can record computer data and audio & video datatogether, as shown in FIG. 3(c). In this example, audio & video dataarea 210 is sandwiched between computer data areas 208 and 209.

[0106] Audio & video data area 210 can record real-time video recordingarea 221 and stream recording area 222 together, as shown in FIG. 3(d).(Either of real-time video recording area 221 or stream recording area222 can be used.) As shown in FIG. 3(e), real-time video recording area221 records RTR navigation data RTR.IFO (VR_MANGR.IFO) 104, moviereal-time video object RTR_MOV.VRO (VR_MOVIE.VRO) 107, still picturereal-time video object RTR_STO.VRO (VR_STILL.VRO) 108, and audio objectRTR_STA.VRO (VR_AUDIO.VRO) 109 such as postrecorded audio or the like,which are shown in FIG. 2.

[0107] Also, as shown in FIG. 3(e), stream recording area 222 recordsstreamer navigation data STREAM.IFO (SR_MANGR.IFO/SR_MANGR.BUP) 105 andtransport bitstream data STREAM.VRO (SR_TRANS.SRO) 106, which are shownin FIG. 2.

[0108] Note that stream recording area 222 can also record navigationdata SR_PRIVT.DAT/SR_PRIVT.BUP 105 a unique to an application shown inFIG. 2, although not shown in FIG. 3(d) and (e).

[0109] This SR_PRIVT.DAT 105 a is navigation data unique to anindividual application connected (supplied) to the streamer, and neednot be recognized by the streamer.

[0110] STREAM.IFO (or SR_MANGR.IFO) 105 as management information thatpertains to stream data has a data structure shown in FIG. 3(f) to (i).

[0111] More specifically, as shown in FIG. 3(f), STREAM.IFO (orSR_MANGR.IFO) 105 is comprised of video manager (VMGI or STR_VMGI) 231,stream file information table (SFIT) 232, original PGC information(ORG_PGCI) 233, user-defined PGC information table (UD_PGCIT) 234, textdata manager (TXTDT_MG) 235, and manufacturer information table (MNFIT)or application private data manager (APDT_MG) 236 that managesnavigation data SR PRIVT.DAT 105 a unique to an application.

[0112] Stream file information table (SFIT) 232 shown in FIG. 3(f) cancontain stream file information table information (SFITI) 241, one ormore pieces of stream object information (SOBI) #A•242, #B•243, . . . ,original PGC information general information 271, and one or more piecesof original cell information #1•272, #2•273, . . . , as shown in FIG.3(g).

[0113] Each stream object information (e.g., SOBI#B•243) shown in FIG.3(g) can contain stream object general information (SOBI_GI) 251, timemap information 252, etc., as shown in FIG. 3(h).

[0114] Each original cell information (e.g., #1•272; corresponding toSCI shown in FIG. 14 to be described later) shown in FIG. 3(g) cancontain cell type 281 (corresponding to C_TY shown in FIG. 14 to bedescribed later), cell ID 282, corresponding cell start time(corresponding to SC_S_APAT shown in FIG. 9(k) and (l) and FIG. 14 to bedescribed later) 283, corresponding cell end time (corresponding toSC_E_APAT shown in FIG. 9(k) and (l) and FIG. 14 to be described later)284, entry point information (SC_EPI) 285, as shown in FIG. 3(h).

[0115] Entry point information (SC_EPI) 285 can be used as a tool forpartially skipping recorded contents. This entry point information(SC_EPI) 285 includes two types (types A and B) depending on thepresence/absence of primary text information (PRM_TXTI), as shown inFIG. 14.

[0116] Note that an entry point indicates an entry position into aprogram in case of an original PGC or an entry position into a portionof a program in case of a user-defined PGC. Such entry points arerecorded as a part of cell information (SCI). These entry points can beused to skip a portion of recorded contents upon playing back therecorded contents.

[0117] All entry points can be specified by application packet arrivaltimes (APAT). This application packet arrival time of the entry point isindicated by EP_APAT in FIG. 14.

[0118] Time map information 252 in FIG. 3(h), which is contained inSOBI#A in FIG. 3(g) can include stream block number 260, first streamblock size 261, second stream block size 262, . . . , and first streamblock time difference 266, second stream block time difference 267, . .. , as shown in FIG. 3(i).

[0119] An example of stream block time difference 266 that forms timemap information 252 is shown in FIG. 1(l). The contents of each streamblock time difference that forms time map information 252 will beexplained later with reference to FIG. 8.

[0120]FIG. 4 is a view for explaining the relationship among streamobjects (SOB), cells, program chains (PGC), etc., in an embodiment ofthe present invention. The relationship between SOB and PGC in thepresent invention will be explained below using an example shown in FIG.4.

[0121] Stream data recorded in stream data (STREAM.VRO or SR_TRANS.SRO)106 form stream blocks as sets of one or more ECC blocks, and recording,a partial erase process, and the like are done in units of streamblocks. The stream data form groups called stream objects in units ofcontents of information to be recorded (e.g., in units of programs indigital broadcast).

[0122] Management information (original PGC information 233,user-defined PGC information table 234, or the like) for each streamobject (SOB#A, SOB#B) recorded in STREAM.VRO (SR_TRANS.SRO) 106 isrecorded in navigation data STREAM.IFO (SR_MANGR.IFO) 105 (see lowermostportion in FIG. 4 and FIG. 3(e) and (f)).

[0123] Two pieces of management information (STREAM.IFO 105) for streamobjects #A•298 and #B•299 in FIG. 4 are recorded as two pieces of streamobject information (SOBI) #A•242 and #B243 in stream file informationtable (SFIT) 232, as shown in FIG. 3(f) and (g).

[0124] Each of stream object information (SOBI) #A•242 and #B243contains time map information 252 that mainly describes the data size,time information, and the like in units of stream blocks.

[0125] Upon playing back stream data, information (corresponding toPGCI#i in FIG. 14 to be described later) of a program chain (PGC) madeup of one or more successive cells is used. Stream data can be playedback in accordance with the order in which the cells that form this PGCare set.

[0126] There are two types of PGCS, i.e., original PGC 290 (ORG_PGCI•233in FIG. 3(f)) which can continuously play back all stream data recordedin STREAM.VRO (SR_TRANS.SRO) 106, and user-defined PGCs #a•293 and#b•296 (corresponding to the contents of UD_PGCIT•234 in FIG. 3(f)) thatcan set arbitrary locations and order of user choice.

[0127] Original cells #1•291 and #2•292 that form original PGC 290basically have one-to-one correspondence with stream objects #A•298 and#B•299.

[0128] By contrast, user-defined cells #11•294, #12•295, and #31•297that form the user-defined PGC can set arbitrary locations within therange of one stream object #A•298 or #B•299.

[0129] A cell range can be designated by designating its start and endtimes. More specifically, in the example shown in FIG. 1(k), the valuesof first time stamp la and last time stamp 321 a in corresponding streamobject #B•299 are used as the values of corresponding cell start and endtimes 283 and 284 (FIG. 3(h)) in original cell #2•292 before executionof partial erase or edit (immediately after recording of stream data).

[0130] By contrast, the time range in user-defined cell #11•294 in FIG.4 can designate arbitrary times, and the values of time stampscorresponding to designated transport packets can be set as the valuesof corresponding cell start and end times.

[0131] As a method of accessing stream data in the stream object,playback of which is to begin, this embodiment can use two methods:

[0132] (1) a method of accessing data using the total recorded data sizefrom the recording start position of each stream object; and

[0133] (2) a method of accessing data taking the decode timing of adecoder into consideration in correspondence with video compression byMPEG.

[0134] As can be seen from FIG. 1(g), all transport packets areadditionally recorded with time stamp information, and each transportpacket can be accessed using this time stamp information.

[0135] When a DVD-RAM disc is used as an information storage medium, ECCblocks are formed every 16 sectors. In an embodiment of the presentinvention, stream data are grouped in units of integer multiples (e.g.,twice) of ECC blocks, and an elapsed time table is provided to eachgroup, thus allowing the method (1) of “accessing data using the totalrecorded data size”. The method (2) of “accessing data taking the decodetiming of the decoder into consideration” will be explained in detaillater in the description of FIG. 11.

[0136] In an embodiment of the present invention, time map information252 is recorded as elapsed time tables in units of groups. This time mapinformation is recorded in a portion of stream object information#A•242; #B•243) corresponding to each stream object, as shown in FIG.3(g) and (h).

[0137] In an embodiment of the present invention, each group (sectorsgrouped in units of two ECC blocks) is called a stream block (or a dataunit called an SOBU) (see upper portion in FIG. 4 or FIG. 1(i)).

[0138] A time stamp is often not allocated at the start position of asector which is allocated at the head position of each stream block(SOBU). In such case, it is difficult to define elapsed times in unitsof stream blocks (SOBUs).

[0139] Following measures can be taken against such situation.

[0140] A) A time stamp value allocated at a specific position of eachstream block is used as a time unique to that stream block.

[0141] More specifically, the value of a time stamp which is allocatedfirst in each stream block (and its recording did not start from theprevious sector) is used as the start time of each stream block.

[0142] B) The differential time between unique times (each start times)in units of stream blocks is defined as an elapsed time of each streamblock.

[0143] C) The elapsed time (differential time) information is recordedin time map information 252.

[0144] Using the differential time (elapsed time), the data size can bereduced. However, an embodiment of the present invention is not limitedto such specific information, and each stream block unique time may berecorded in time map information 252.

[0145] D) The rounded value of the elapsed time (differential time)information is recorded in time map information 252.

[0146] By rounding the computation result of the elapsed time(differential time) information (by counting fractions as one orrounding off), the rounded value is recorded in time map information252, thus reducing the data size.

[0147] E) The stream block boundary position set upon initial recordingremains unchanged even in stream data after partial erase.

[0148] Note that the sector size of each stream block can be variouslyset. As a preferred embodiment, a stream object unit (SOBU) made up oftwo ECC blocks (32 sectors) and having a constant size (64k bites) canbe used as a stream block like stream block #μ in FIG. 4.

[0149] When the stream block is fixed to be an SOBU having a constantsize (e.g., 2 ECC blocks=32 sectors =64k bites), the following meritsare obtained.

[0150] (01) Even when stream data is erased or rewritten in units ofSOBUS, an ECC block of that SOBU does not influence ECC blocks of SOBUsother than the SOBU to be erased or rewritten. For this reason, ECCdeinterleave/interleave upon erase or rewrite (for SOBUs other than theSOBU to be erased or rewritten) need not be done; and

[0151] (02) An access position to recorded information in an arbitrarySOBU can be specified by the number of sectors (or a parametercorresponding to the number of sectors; e.g., information of streampacks or application packets therein). For example, when the middleposition of given SOBU#k is to be accessed, the 16th sector position (orapplication packet position corresponding to the 16th sector position)from the boundary between SOBU#k-1 and SOBU#k can be designated.

[0152]FIG. 5 is a view for explaining the correspondence among thedigital broadcast contents, the video data transfer format in IEEE1394,and stream packs in the streamer.

[0153] In digital broadcast, video information compressed according toMPEG2 is transferred in transport packets. Digital broadcast adopts amulti-program compatible multiplexing/demultiplexing scheme called atransport stream, as shown in FIG. 5(c), and one transport packet b 322often has a size of 188 bytes (or 183 bytes).

[0154] Each transport packet is made up of transport packet header 311,and payload 312 that records a data main body of recording information,as shown in FIG. 5(b).

[0155] Transport packet header 311 is comprised of payload unit startindicator 301, packet ID (PID) 302, random access indicator 303, programclock reference 304, playback time stamp (PTS) 305, and the like, asshown in FIG. 5(a).

[0156] The MPEG-compressed video information contains I-,B-, andP-picture information. In the first transport packet that recordsI-picture information, random access indicator 303 in FIG. 5(a) is setwith flag= “1”. On the other hand, in the first transport packets ofB-picture information and P-picture information, payload unit startindicator 301 in FIG. 5(a) is set with flag=“1”.

[0157] Using information of these random access indicator 303 andpayload unit start indicator 301, information of an I-picture mappingtable and information of a B/P-picture start position mapping table aregenerated.

[0158] For example, a bit at the corresponding position in theB/P-picture start position mapping table is set at “1” for a transportpacket having payload unit start indicator 301 shown in FIG. 5(a) setwith flag=“1”.

[0159] In digital broadcast, video information and audio information aretransferred in different transport packets. The video information andaudio information are distinguished by packet ID (PID) 302 in FIG. 5(a).Using information of this PID 302, a video packet mapping table and anaudio packet mapping table can be generated.

[0160] As shown in FIG. 5(c), a plurality of programs (programs 1 to 3in this example) are time-divisionally transferred while beingpacketized in a single transponder. For example, information oftransport packet header 311 and that of payload (recording information)312 in FIG. 5(b) are transferred by transport packets b 522 and e 525 ofprogram 2 shown in FIG. 5(c).

[0161] In IEEE1394, as shown in FIG. 5(e) and (f), each of IEEEisochronous headers 343 and 344 includes isochronous packet header 351and common isochronous packet header 352. In this common isochronouspacket header 352, a format-dependent reserve area is set.

[0162] In an embodiment of the present invention, as shown in FIG. 5(g),the format-dependent reserve area in common isochronous packet header352 stores source ID 361, data block size information 362, and I-picturestart position flag 363. Since I-picture start position flag 363 is setin the format-dependent reserve area in this manner, the I-pictureposition in stream data can also be designated in real time (i.e., atransport packet corresponding to the start position of I-picture can bedesignated) simultaneously with transfer of stream data in theisochronous mode. This is a great feature of this embodiment.

[0163] Note that the end portion of an application packet area in FIG.5(h) may often become blank in place of recording former half 346 oftransport packet b of program 2. In this case, the end portion of theapplication packet area becomes a stuffing area (having no time stamp atits head position) having the reserved number of bytes.

[0164] A normal packet is appended with a time stamp. However, as shownin FIG. 5(i), a time stamp can be omitted in a partial packet.

[0165] In this manner, partial packets (the partial packet size fallswithin the range from 1 to 187 bytes if the packet size is 188 bytes; anaverage of less than 100 bytes) divided at the boundary of twoneighboring stream packs (FIG. 5(j)) can be effectively used ininformation recording. In addition, the storage capacity of medium 201can be increased by an amount of each time stamp (e.g., 4 bytes per timestamp) omitted from a partial packet.

[0166] Note that the position of a time stamp located immediately afterthe first packet in FIG. 5(i) can be specified by first access point 56in FIG. 1(a), or FIRST_AP_OFFSET shown in FIG. 10(c).

[0167]FIG. 6 is a view for explaining the sector structure that storesdata of a stream object.

[0168]FIG. 6(a) to (d) show contents corresponding to FIG. 1(h) to (k).In the example shown in FIG. 6, all stream blocks (SOBUS) #α to #γ havea fixed size (32 sectors/2 ECC blocks=64k bites). FIG. 6(f) to (j) showthe pack structure that form last sector No. n of stream block (SOBU) #γand its immediately preceding sector No. n-1 (FIG. 6(e)).

[0169] Each sector of stream block (SOBU) #γ has a similar datastructure except for last sector No. n. For example, sector No. n-1 hasa data structure, as shown in FIG. 6(f).

[0170] More specifically, sector No. n-1 is made up of a stream pack of2,048 bytes (2k bytes). This stream pack is comprised of a 14-byte packheader and 2,034-byte stream PES packet.

[0171] The stream PES packet is comprised of a 6-byte PES header, 1-bytesubstream ID, and 2,027-byte stream data area.

[0172] The stream data area consists of a 9-byte application header,application header extension (option), stuffing byte (option), andapplication packet area.

[0173] The application packet area in FIG. 6(f) can have the samestructure as that shown in FIG. 5(h) and (i) (change “packet” in FIG.5(h) to read “application packet in FIG. 6).

[0174] The application packet area is made up of a group of applicationpackets each having an application time stamp (ATS) at its head position(except for a stuffing area in FIG. 5(h) and a partial packet in FIG.5(i)). For example, when a transport packet having a 188-byte size isstored as an application packet in the application packet area,approximately 10 application packets can be stored in the applicationpacket area.

[0175] In stream recording, an application that generates recordingcontents makes stuffing by itself to obviate the need for independentadjustment of the pack length. For this reason, in stream recording astream pack can always have a required length (e.g., 2,048 bytes). Thestuffing byte in FIG. 6(f) is used to maintain the predetermined length(2,048 bytes) of a stream pack.

[0176] Last sector No. n of stream block (SOBU) #γ has a data structureshown in FIG. 6(g) to (j). That is, as shown in FIG. 6(g), last sectorNo. n consists of a pack header and padding packet. This padding packetincludes padding area 21 (corresponding to padding area 21 in FIG. 1(k))in its application packet area, as shown in FIG. 6(h).

[0177] The first application packet area in padding area 21 is stuffedwith a stuffing packet (zero-byte data having essentially no recordingcontents) with an application time stamp (ATS), as shown in FIG. 6(i).If padding area 21 has a length for a plurality of sectors, the secondor subsequent application packet area (subsequent stuffing packet) isstuffed with a stuffing packet (zero-byte data) without any ATS, asshown in FIG. 6(j).

[0178] When recording is done at very low bit rate, the stuffing byte isrequired to ensure recovery (playback) of time map information (252 inFIG. 3(h); or MAPL in SOBI in FIG. 15 to be described later). Thestuffing packet in FIG. 6(i) or FIG. 6(j) is defined as a conceptualunit for that purpose.

[0179] The objective of this stuffing packet is achieved when each SOBUincludes at least one ATS value as well as the stuffing area.

[0180] The following conditions are imposed on the stuffing packet:

[0181] One or a plurality of stuffing packets always start from theapplication packet area of a pack after a pack including actualapplication packet data; and

[0182] One or a plurality of stuffing packets consist of one 4-byte ATS,and zero byte data (following ATS) required to stuff the applicationdata area of the remaining pack of the SOBU of interest. Assuming thatSOBU_SIZ represents the number of sectors per SOBU, if 0≦n≦SOBU_SIZ−1,the total length of the stuffing packet is “4+2,014+n×2,018” bytes.

[0183] ATS of the stuffing packet is set as follows:

[0184] In an SOBU in which at least one pack includes actual applicationpacket data, ATS of the stuffing packet is set to be that of anapplication packet preceding the stuffing packet; and

[0185] In an SOBU that does not include any actual application packet,ATS of the stuffing packet is determined in accordance with the contentsof time map information or the like.

[0186] All packs each of which includes the stuffing packet or a portionof the stuffing packet are configured as follows:

[0187] SCR of the pack header is set to be the sum of SCR of thepreceding pack and “2,048×8 bits÷10.08 Mbps”;

[0188] The PES packet header and substream ID are the same as those ofall other PES packets; and

[0189] In the application header (see FIG. 10(c) and (d)), AP_Ns=0,FIRST_AP_OFFSET=0, EXTENSION_HEADER_IFO=00b, and SERVICE_ID=0 (otherparameters in the application header are set at zero).

[0190]FIG. 7 is a view for explaining the relationship between the videoinformation compression method in MPEG and transport packets, and therelationship between transport packets in MPEG and application packetsin the streamer.

[0191] As shown in FIG. 7, broadcast signal information in digital TVadopts a signal compression method called MPEG2. In the signalcompression method based on MPEG, images (pictures) for TV display arecategorized into I-picture 501 that does not contain any timedifferential information, and B-pictures 503 and 504 and P-picture 502which contain time differential information.

[0192] I-picture independently exists without being influenced by theprevious or next image (picture) information, and after DCTtransformation for a single image (picture), quantized informationbecomes I-picture compressed information 511 and is recorded asI-picture information 521. As for P-picture 502, only differentialinformation 512 from I-picture 501 is recorded as P-picture information522. As for B-picture 503, two pieces of differential information 513and 514 from I-picture 501 and P-picture 502 are recorded as B-pictureinformation 523, and as for B-picture 504, two pieces of differentialinformation 515 and 516 from I-picture 501 and P-picture 502 arerecorded as B-picture information 524.

[0193] As shown in FIG. 7, compressed information 511 of I-picture 501is recorded in transport packets 1 a, 1 b, . . . as I-pictureinformation 521, two pieces of differential information 513 and 514 ofB-picture are recorded in transport packets 33 a, . . . as B-pictureinformation 523, two pieces of differential information 515 and 516 ofB-picture are recorded in transport packets 41 d, . . . as B-pictureinformation 524, and P-picture differential information 512 is recordedin transport packets (TP) 48 h to 298 h as P-picture information 522. Inthis way, I-, B-, and P-picture information are recorded in differenttransport packets.

[0194] Upon video playback, P-picture 502 or B-pictures 503 and 504cannot solely generate images, but can generate picture images onlyafter the image of I-picture 501 is generated. Pieces of pictureinformation 521 to 524 are divisionally recorded in the payloads of oneor a plurality of transport packets. At this time, the information isrecorded so that the boundary position of each of picture information521 to 524 always matches that between neighboring transport packets, asshown in FIG. 7.

[0195] In first transport packet la that records I-picture information521, random access indicator 303 (FIG. 5(a)) is set with flag=“1”. Onthe other hand, in first transport packets 33 a, 41 a, and 48 h ofpieces of B-picture information 523 and 524 and P-picture information522, payload unit start indicator 301 (FIG. 5(a)) is set with flag=“1”.Using information of random access indicator 303 and payload unit startindicator 301, I-picture position flag 58 and picture head position flag59 in FIG. 1(a) are generated. Likewise, pieces of information such ascipher information 60 used in copy protection and the like are recordedas bitmap information 43 (FIG. 5(b)) that pertains to individualtransport packets.

[0196] Position information (I-picture position information) ofI-picture (501) in FIG. 7 is recorded as entry point information(SC_EPI) 285 in original cell information (SCI) (#1•272 or the like), asshown in FIG. 3(g) and (h).

[0197] The data structure in entry point information 285 has a listformat of information of entry point positions (first entry pointposition (EP_APAT) 531, second entry point position 532, third entrypoint position 533, . . . , last entry point position 535) indicatingindividual I-picture position information present in a single streamobject, as shown in FIG. 7(a) and (b).

[0198] As the information contents of entry point position (EP_APAT)531, the value of time stamp la corresponding to transport packet lathat records the first information of I-picture information 521 isrecorded, as shown in FIG. 7(a). As the information contents ofindividual entry point positions (EP_APAT) 532, 533, and 535 as well,the values of time stamps 87 f, 183 d, and 298 g corresponding totransport packets that record the first information of the correspondingI-picture information are similarly recorded.

[0199] The corresponding cell start time information and/or thecorresponding cell end time information for user-defined cell #11•294shown in FIG. 4 are/is recorded in user-defined PGC information table234 in FIG. 3(f). In this case, when the user wants to play back fromB-picture information 524 in FIG. 7, he or she can set time stamp 41 das the corresponding cell start time. In this manner, the correspondingcell start or end time information can be set using arbitrary time stampinformation irrespective of the I-picture position.

[0200] On the other hand, the start/end time of a stream object in thisembodiment is set in consideration of the I-picture position. That is,as the information contents of stream object general information 251shown in FIG. 3(h) and (d), recording time (SOB_REC_TM) 541 indicatingthe recording start time, stream object start time (SOB_S_APAT) 542, andstream object end time (SOB_E_APAT) 543 are recorded, as shown in FIG.7(c).

[0201] This stream object start time (SOB_S_APAT) 542 must be set withthe value of time stamp 1 a corresponding to transport packet 1 a thatrecords first I-picture information 521. Likewise, stream object endtime (SOB_E_APAT) 543 must be set with the value of time stamp 298 gcorresponding to transport packet 298 g immediately before I-pictureinformation.

[0202] When transport packets in FIG. 7 are recorded by the streamer(optical disc device 415 in FIG. 11 to be described later), the contentsof transport packets are transplanted to packets (application packets)with time stamps called application time stamps (ATS).

[0203] A group of application packets with ATS (normally, around 10packets) are stored in an application packet area in a stream PESpacket.

[0204] One stream pack is formed by appending a pack header to thisstream PES packet. The stream PES packet is made up of a PES header,substream ID, application header, application header extension (option),stuffing bytes (option), and application packet area for storing thegroup of application packets with ATS.

[0205]FIG. 8 is a view for explaining the method of setting time mapinformation 252 shown in FIG. 1, etc.

[0206] As shown in FIG. 1(g) or FIG. 8(b), stream data recorded bysequentially packing time stamps (TMS) and transport packets (TP) (orapplication packets AP) are segmented in units of two ECC blocks (32sectors) to form stream blocks (SOBUs) #α, #β, #β, . . . , #λ, as shownin FIG. 8(a).

[0207] Time stamp (TMS) la is allocated at the head position of streamblock (SOBU) #α. This time stamp 1 a indicates the arrival time(SOBU_S_APAT) of the first packet of SOBU#α. The value [0] of this timestamp 1 a is used as the start time of SOBU#α.

[0208] For other stream blocks (SOBU#β to SOBU#λ), the values ([28],[63], [98], [297]) of time stamps 33 a, 65 a, 98 a, . . . , 321 alocated at the head positions of these stream blocks under the conditionthat they did not start in the previous sectors are used as the starttimes of the respective stream blocks (SOBU#β to SOBU#λ).

[0209] Last time stamp 300 a immediately before the last packet in eachstream block, e.g., last SOBU#λ, indicates the arrival time(SOBU_E_APAT) of the last packet of SOBU#λ. The value [300] of this timestamp 300 a is used as the end time of SOBU#λ.

[0210] When a blank area is formed at the end of last SOBU#λ, this blankarea is set as padding area 21 having no actual data (see FIG. 1(k) orFIG. 6(h) and (i)).

[0211] Assume that the start times of the respective stream blocks(SOBU#α to SOBU#λ) are respectively 0, 28, 63, 98, . . . , 297, as shownin FIG. 8(b). These times are indicated by one of (a) seconds, (b) thenumber of fields or frames/pictures (e.g., 30 pictures/sec or 60fields/sec for NTSC; 25 pictures/sec or 50 fields/sec for PAL), and (c)a count value based on reference clocks of 27 MHz or 90 kHz.

[0212] In the example shown in FIG. 8(a) and (b), the elapsed time ofthe first stream block (SOBU#α) is [28]−[0]=[28] (the number ofeffective digits=2). However, since no practical problem is posed if acoarser expression of the elapsed time is used, the units digit isrounded (the retained digit is increased by one) to [30].

[0213] The elapsed time of the second stream block (SOBU#β) is [63]−[30]if the rounded result [30] is used. Likewise, the units digit is rounded(the retained digit is increased by one) to [40]. Similarly, the elapsedtimes of the subsequent stream blocks (SOBU#γ to SOBU#λ) are expressedby numerical values rounded to the number of effective digits=1 (theretained digit is increased by one).

[0214] Note that since a stream block after the stream block (SOBU#λ) isnot accessed, the time difference value for the last stream block isblank, as shown in FIG. 8(c).

[0215]FIG. 8(c) shows the relationship between the rounded results andtime map information 252.

[0216] Since there is no stream block after the stream block (SOBU#λ), asimilar differential time computation with another stream block cannotbe done. Hence, this embodiment allows the following method for only thelast stream block (SOBU#λ). That is, the difference between the value ofthe last time stamp recorded therein (the value [300] of time stamp 300a in the example in FIG. 8(b)) and the value of the first time stampvalue recorded in the last stream block (SOBU#λ) (the value [297] oftime stamp 321 a in the example in FIG. 8(b)) is calculated, and itsrounded value is set as the time difference value. FIG. 8(d) shows thisexample.

[0217] Note that the time difference value of last SOBU#λ in FIG. 8(d)can be calculated by two methods. In the first method, the value [300]before rounding of last time stamp 300 a (SOBU_E_APAT of SOBU#λ) and thevalue [297] before rounding of first time stamp 321 a are used, and thetime difference value [10] is calculated by rounding their difference[3]. In the second method, the rounded value [300] of last time stamp300 a, and the rounded value [300] of first time stamp 321 a are used,and the time difference value [10] is calculated by adding a round error[10] to their difference [0].

[0218] In the second method, [0] at the units digit of each numericalvalue may be removed to obtain a numerical value having the number ofeffective digits=1, and a round error [1] may be used to remove unitsdigits of other numerical values.

[0219]FIG. 9 is a view for explaining changes in stream objectinformation and original cell information before and after the recordedstream object is partially erased.

[0220] A series of information description methods mentioned above canbe applied to a partially erased stream object. FIG. 9(k) shows a statebefore partial erase, and the stream data structure that pertains to astream object, original cell range, and stream object range immediatelyafter recording (SOB#B•299 in FIG. 1(h), etc.) are shown in FIG. 9(a) to(e).

[0221] The process after portions before and after the range from timestamps 97 c to 224 c as an actual display range are partially erasedwill be explained below.

[0222] In this embodiment, partial erase is done in units of sectors.However, in order to play back another stream object immediately after astream object after partial erase is played back, and to attain seamlessplayback without disturbing images at the boundary of these streamobjects, partial erase must be done while holding the GOP boundaryposition of an MPEG bitstream.

[0223] Assume that the I-picture head position immediately beforetransport packet 97 c corresponding to time stamp 97 c is present intransport packet 87 f, as indicated by a second entry point position 532in FIG. 7(a). In this case, sector No. 87 including transport packet 87f is left, all sectors before that sector are erased, and the value ofthis time stamp 87 f is set to be stream object start time (SOB_S_APAT)542 (see FIG. 9(l)) of the stream object before partial erase.

[0224] As a result, the size of stream block #γ decreases from 32sectors to 30 sectors.

[0225] At the same time, the value of the stream block time differencedescribed in time map information 252 in correspondence with the blocksize decreases from, e.g., 40 to 30. Since the boundary positions amongstream blocks #8 to #η remain unchanged before and after partial erase,the information contents in time map information 252 which pertain tothat portion remain the same.

[0226] If the I-picture head position starts from transport packet 225 e(not shown in FIG. 7), sectors up to sector No. 225 in FIG. 9(i) thatincludes transport packet 225 d are left, and all sectors after thatsector are erased.

[0227] Stream object end time (SOB_E_APAT) 543 in FIG. 9(j) can be setby time stamp 225 d of transport packet 225 d.

[0228] Corresponding cell start time (SC_S_APAT) 283/end time(SC_E_APAT) 284 after partial erase are respectively set by time stamps97 c and 224 k in correspondence with the actual designation range ofpartial erase, as shown in FIG. 9(i).

[0229] A characteristic feature of this embodiment lies in that time mapinformation (or stream object information SOBI/original cell informationSCI) is generated by such method.

[0230] Note that the start time and/or end time before and after partialerase change or changes, but the SOBU size remains unchanged (e.g.,fixed at 64k bites for 32 sectors).

[0231] Partial erase may be done in units of SOBUs. In this case, first(or last) time stamp TMS in an original cell is included in the first(or last) SOBU in an SOB.

[0232]FIG. 10 is a view for explaining the data structure of a streampack shown in FIG. 5, etc.

[0233] Each stream pack has a data structure shown in FIG. 10(d). Onestream pack is formed by 14-byte pack header 11, 6-byte PES header 601,a 1-byte substream ID, a 9-byte application header, an applicationheader extension (option) which is used as needed, a stuffing byte(option) which is used as needed, and an application packet groupincluding one or more application packets each appended with applicationtime stamp ATS (see FIG. 6(f)).

[0234] Pack header 11 contains pack start code information, system clockreference (SCR) base information, SCR extension information, programmultiplexing rate information, pack stuffing length information, and thelike, as shown in FIG. 10(g). The SCR base consists of 32 bits, and its32nd bit is zero. As the program multiplexing rate, for example, 10.08Mbps are used.

[0235] The PES header includes packet start code prefix information,stream ID (private stream 2) information, and PES packet lengthinformation, as shown in FIG. 8(f).

[0236] The substream ID has contents for specifying stream recordingdata, as shown in FIG. 8(f). More specifically, substream ID=“00000010b”indicates that data stored in that stream pack is stream recording data.When this stream ID is “10111110b”, it indicates that the stream pack ofinterest is used as a padding packet (see FIG. 6(g)).

[0237] The application header in FIG. 10(d) includes versioninformation, the number AP_Ns of application packets, time stampposition FIRST_AP_OFFSET of the first application packet, extensionheader information EXTENSION_HEADER_IFO, service ID, and the like, asshown in FIG. 10(c).

[0238] Note that the version describes the version number of theapplication header format.

[0239] AP_Ns in the application header describes the number ofapplication packets that start within the stream pack of interest. Ifthe stream pack of interest stores the first byte of ATS, it isdetermined that an application packet starts in this stream pack.

[0240] FIRST_AP_OFFSET describes the time stamp position of the firstapplication packet that starts within the stream packet of interest as arelative value (unit: byte) from the first byte in this stream packet.If no application packet starts within the stream packet,FIRST_AP_OFFSET describes “0”.

[0241] EXTENSION_HEADER_IFO describes whether or not an applicationheader extension and/or stuffing byte are/is present within the streampacket of interest.

[0242] If the contents of EXTENSION_HEADER_IFO are 00 b, it indicatesthat neither the application header extension nor stuffing byte arepresent after the application header.

[0243] If the contents of EXTENSION_HEADER_IFO are 10 b, it indicatesthat the application header extension is present after the applicationheader, but no stuffing byte is present.

[0244] If the contents of EXTENSION_HEADER_IFO are 11 b, it indicatesthat the application header extension is present after the applicationheader, and the stuffing byte is also present after the applicationheader extension.

[0245] The contents of EXTENSION_HEADER_IFO are inhibited from assuming01 b.

[0246] The stuffing byte (option) before the application packet area isactivated by “EXTENSION_HEADER_IFO 11b”. In this manner, “packingparadox” can be prevented when the number of bytes in the applicationheader extension is contradictory to the number of application packetsthat can be stored in the application packet area.

[0247] SERVICE_ID describes the ID of a service that ,generates thestream. If this service is unknown, SERVICE_ID describes 0×0000.

[0248] FIRST_AP_OFFSET in FIG. 10(c) corresponds to first access point56 in FIG. 10(b) or FIG. 1(a). This first access point 56 is stored insearch information 42 (see FIG. 1(b)) in the pack header (or applicationheader), as shown in FIG. 10(a).

[0249] The stuffing byte and application packet group in FIG. 10(d) forman application packet area, as shown in FIG. 6(f). A partial applicationpacket is recorded at the head position of this application packet area.After this packet, a plurality of pairs of application time stamps ATSand application packets are sequentially recorded. At the end of theapplication packet area, a partial application packet (or stuffing areawith the reserved number of bytes) is recorded, as shown in FIG. 5(h).

[0250] In other words, a partial application packet can be present atthe start position of the application packet area, and a partialapplication packet or a stuffing area with a reserved number of bytescan be present at the end position of the application packet area.

[0251] The application time stamp (ATS) allocated before eachapplication packet consists of 32 bits (4 bytes). This ATS can bedivided into two fields, i.e., a basic field and extended field. Thebasic field is called a 90-kHz unit value, and the extended fieldindicates a less significant value measured at 27 MHz.

[0252] In FIG. 10(d), the application header extension can be used tostore information which can differ between application packets. Suchinformation is not always required for all applications. Therefore, thedata field of the application header is defined to be able to describethe presence of the application header extension as an option in thestream data area (in EXTENSION_HEADER_IFO mentioned above).

[0253] Upon recording a stream, the first byte of application time stampATS of the first application packet must be aligned to the startposition of the application packet area in the first stream packet atthe beginning of stream object SOB.

[0254] On the other hand, as for the subsequent stream packet in theSOB, an application packet may be segmented (split) at the boundary ofneighboring stream packets.

[0255] Two transport packets 1 k shown in FIG. 1(g) or partialapplication packets shown in FIG. 5(h) and (i) indicate applicationpackets formed by this segmentation (split).

[0256] The byte offset of the first application time stamp that startswithin the stream packet and the number of application packets whichstart within that stream packet are described in the application header.With this format, stuffing before the first application time stamp andafter the last application packet is automatically done in a givenstream packet.

[0257] That is, the automatic mechanism allows “the application to makestuffing by itself”. With this automatic stuffing, a stream packet canalways have a required length.

[0258] The application header extension (option) consists of a list ofentries. The list includes one entry having a 1-byte lengthcorresponding to each application packet that starts within the streampacket of interest. The bytes of these entries can be used to storeinformation which may differ in units of application packets.

[0259] Note that the 1-byte application header extension (option)describes 1-bit AU_START, 1-bit AU_END, and 2-bit COPYRIGHT, as shown inFIG. 10(e).

[0260] When AU_START is set at “1”, it indicates that a relatedapplication packet includes a random access entry point (start of arandom access unit) within the stream. When AU_END is set at “1”, itindicates that a related application packet is the last packet of therandom access unit. COPYRIGHT describes the state of copyright of arelated application packet.

[0261] The packet structure shown in FIG. 10 can be applied to sectorsother than the last sector of the stream object (SOB) of interest, butcannot always be applied to the last sector. The packet structure shownin FIG. 6(i) and (j) is applied to the last sector.

[0262]FIG. 11 is a block diagram for explaining the arrangement of astream data recording/playback system (optical disc device/streamer, STBunit) according to an embodiment of the present invention. Thisembodiment assumes as information storage medium 201 arecordable/reproducible optical disc such as a DVD-RAM disc or the like.

[0263] The internal structure of the stream data recording/playbackapparatus according to an embodiment of the present invention will bedescribed below using FIG. 11.

[0264] This stream data recording/playback apparatus comprises opticaldisc device 415, STB unit 416, and their peripheral devices.

[0265] The peripheral devices include video mixing unit 405, framememory 406, external loudspeaker 433, personal computer (PC) 435,monitor TV 437, D/A converters 432 and 436, I/F units 431 and 434, andthe like.

[0266] Optical disc device 415 comprises recording/playback unit 409including a disc drive, data processor (to be abbreviated as D-PROhereinafter) 410 for processing stream data to recording/playback unit409 (or stream data from recording/playback unit 409), temporary storage411 for temporarily storing stream data that overflows from D-PRO 410,and optical disc device controller 412 for controlling operations ofrecording/playback unit 409 and D-PRO 410.

[0267] Optical disc device 415 further comprises data transfer interface414 for receiving stream data sent from STB unit 416 via IEEE1394 or thelike (or sending stream data to STB unit 416 via IEEE1394 or the like),and formatter/deformatter 413 for converting the stream data received bydata transfer interface 414 into a signal format that can be recorded oninformation storage medium (RAM disc) 201 (or converting the stream dataplayed back from medium 201 into a signal format for, e.g., IEEE1394 orthe like).

[0268] The IEEE1394 reception side of data transfer interface 414 readsthe time from the start of stream data transfer on the basis of the timecount value of reference clock generator (system time counter STC) 440.

[0269] Based on the time information, delimiter information for dividingstream data in units of stream blocks (or in units of SOBUs) isgenerated, and cell division information, program division information,and PGC division information are generated in correspondence with thisdelimiter information.

[0270] Formatter/deformatter 413 converts the stream data sent from STBunit 416 into a stream pack sequence (see FIG. 5(j), etc.), and inputsthe converted stream pack sequence to D-PRO 410. Each of the inputstream packs has a constant size of 2,048 bytes, which is equal to thesector size. D-PRO 410 combines the input stream packs in units of 16sectors to form ECC blocks, and sends the ECC blocks torecording/playback unit 409.

[0271] When recording/playback unit 409 is not ready to record data onmedium 201, D-PRO 410 transfers recording data to temporary storage 411to temporarily save them therein, and waits until recording/playbackunit 409 is ready to record data.

[0272] When recording/playback unit 409 is ready to record data, D-PRO410 transfers data saved in temporary storage 411 to recording/playbackunit 409. In this manner, recording on medium 201 is started. Uponcompletion of recording of data saved in temporary storage 411, thesubsequent data are seamlessly transferred from formatter/deformatter413 to D-PRO 410. Assume that a large-size memory is used as temporarystorage 411 so as to store recording data for several minutes or more byhigh-speed access.

[0273] Note that time stamp information appended to the recordingbitstream via formatter/deformatter 413 can be obtained from referenceclock generator (STC) 440. On the other hand, time stamp information(SCR) extracted from the playback bitstream via formatter/deformatter413 can be set in STC 440.

[0274] Each pack header in the stream data recorded on informationstorage medium 201 records a reference clock (system clock referenceSCR). When the stream data (SOB or SOBU) recorded on this medium 201 isplayed back, reference clock generator (STC) 440 is adjusted to thereference clock (SCR) played back from medium 201 (the SCR value is setin STC 440).

[0275] That is, in order to play back SOB or SOBU data, the referenceclock (STC 440) in the streamer (optical disc device 415) is adjusted tosystem clock reference SCR described in the first stream pack from whichplayback starts. After that, STC 440 is automatically counted up.

[0276] STB unit 416 comprises demodulator 422 for demodulating thecontents of a digital broadcast wave received by satellite antenna 421,and providing demodulated data (stream data) that multiplexes one ormore programs, and reception information selector 423 for selectinginformation of a specific program (of user's choice) (taking FIG. 5 asan example, a transport packet of program 2) from data demodulated bydemodulator 422.

[0277] When the information (transport packet) of the specific programselected by reception information selector 423 is to be recorded oninformation storage medium 201, selector 423 sends stream datacontaining only the transport packet of the specific program to datatransfer interface 414 of optical disc device 415 by IEEE1394 transfervia data transfer interface 420 in accordance with an instruction fromSTB controller 404.

[0278] Data transfer interface 414 in optical disc device 415temporarily converts stream data transferred according to IEEE1394 intothe format shown in FIG. 5(d), and pairs of time stamps and transportpackets as shown in FIG. 5(d) are packed and recorded in turn oninformation storage medium 201.

[0279] When the user merely reviews the information (transport packet)of the specific program selected by reception information selector 423without recording it, selector 423 sends stream data containing only thetransport packet of the specific program to multiplexed informationdemultiplexer 425 of decoder unit 402 in accordance with an instructionfrom STB controller 404.

[0280] On the other hand, when a program recorded on information storagemedium 201 is to be played back, stream data sent from optical discdevice 415 to STB unit 416 via an IEEE1394 serial bus is sent tomultiplexed information demultiplexer 425 of decoder unit 402 viaselector 423.

[0281] Multiplexed information demultiplexer 425 classifies variouspackets (video packets, audio packets, and sub-picture packets)contained in the stream data sent from selector 423 on internal memory426 on the basis of their IDs. Then, demultiplexer 425 distributes theclassified packets to corresponding decoders (video decoder 428,sub-picture decoder 429, and audio decoder 430).

[0282] Video decoder 428 decodes (MPEG-encoded) video packets sent frommultiplexed information demultiplexer 425 to generate moving picturedata. Video decoder 428 incorporates representative image (thumbnail)generator 439 to provide a function of generating a reduced-scalepicture (thumbnail picture) that represents the recorded contents fromI-picture in MPEG video data in such case.

[0283] Moving picture data (and/or the representative image generated bygenerator 439) decoded by video decoder 428, sub-picture data(information of superimposed dialogs, menus, and the like) decoded bysub-picture decoder 429, and audio data decoded by audio decoder 430 aresent to video mixing unit 405 via video processor 438.

[0284] Video mixing unit 405 generates a digital video by superposingthe superimposed dialogs and the like on the moving picture using framememory 406. This digital video is converted into an analog video via D/Aconverter 436, and the analog video is sent to monitor TV 437.

[0285] Also, the digital video from video mixing unit 405 is fetched asneeded by personal computer 435 via I/F unit 434 and a signal line suchas IEEE1394 or the like.

[0286] On the other hand, digital audio information decoded by audiodecoder 430 is sent to external loudspeaker 433 via D/A converter 432and an audio amplifier (not shown). Also, decoded audio information isdigitally output to an external device via I/F unit 431.

[0287] Note that the operation timing in STB unit 416 is determined byclocks from system time counter (STC) 424.

[0288] The aforementioned instructions, etc., from STB controller 404(operation control of the internal components of STB unit 416) areexecuted by a control program stored in program memory 404 a. In thiscase, work memory 407 is used as needed in the control process of STBcontroller 404.

[0289] The internal operation timings of STB unit 416 including STBcontroller 404 and decoder unit 402 can be restricted by clocks from STCunit 424. By synchronizing STC 440 of optical disc device 415 with STCunit 424 of STB unit 416, the operation timings of the overall streamersystem including optical disc device 415 and STB unit 416 can berestricted.

[0290] As a method of synchronizing STC 440 with STC unit 424, a methodof setting STC 440 and STC unit 424 using a reference clock (SCR) instream data exchanged between data transfer interfaces 414 and 420 isavailable.

[0291] In optical disc device 415 (streamer) in FIG. 11, pairs of timestamps and transport packets (FIG. 5(h) and (i)) are recorded oninformation storage medium 201 as they are.

[0292] When the user instructs to record, for example, the secondprogram in FIG. 5(c) on an information storage medium (201 in FIG.3(a)), reception information selector 423 in STB unit 416 shown in FIG.11 extracts only transport packets b and e of program 2. At that time,STB unit 416 appends reception time information of transport packets b522 and e 525 in the form of time stamps 331 and 332, as shown in FIG.5(d).

[0293] After that, when data is transferred to formatter/deformatter 413in FIG. 11 according to the IEEE1394 transfer scheme, the pairs of timestamps and transport packets are transferred while being segmented intosmall units, as shown in FIG. 5(e).

[0294] Formatter/deformatter 413 in FIG. 11 temporarily converts streamdata transferred by IEEE1394 from STB unit 416 into the format shown inFIG. 5(d) (corresponding to the format shown in FIG. 1(g)). A bitstreamin the format shown in FIG. 5(d) (a stream pack sequence in FIG. 5(j))is recorded on information storage medium 201. More specifically, in anembodiment of the present invention, pack headers and PES headers whichrecord system clock information and the like are inserted at the headpositions of respective sectors (see FIG. 5(j), etc.).

[0295] A plurality of time stamps and transport packets (FIG. 1(g)) arepacked in data areas (FIG. 1(f)), and one transport packet (packet 1 kin FIG. 1(g); packet b of program 2 in FIG. 5(d)) is recorded across aplurality of sectors (Nos. 0 and 1 in FIG. 1(e); partial packets in FIG.5(h) and (i)). This is one feature of the present invention.

[0296] Using the data structure that utilizes this feature, a packethaving a size larger than the sector size (e.g., 2,048 bytes) can berecorded. This point will be described in more detail below.

[0297] Digital broadcast adopts a multi-program compatiblemultiplexing/demultiplexing scheme called a transport stream, as shownin FIG. 5(c), and one transport packet b•522 often has a size of 188bytes (or 183 bytes). As described above, one sector size is 2,048bytes, and each data area (FIG. 1(f)) can record approximately 10transport packets for digital broadcast even after various header sizesare subtracted. By contrast, in a digital communication network such asISDN or the like, a long packet having a packet size as large as 4,096bytes is often transferred.

[0298] Using the data structure that utilizes the feature (capable ofrecording one packet data across a plurality of packets) so that each ofdata areas 21, 22, and 23 (FIG. 1(f)) can record not only a plurality oftransport packets, but also a packet with a large packet size such as along packet, one packet is recorded across a plurality of data areas. Asa result, all packets, i.e., transport packets for digital broadcast, along packet for digital communications, and the like can be recorded ina stream block without any fractions independently of their packetsizes.

[0299] The device arrangement in STB unit 416 shown in FIG. 11 can befunctionally divided/categorized into a “reception time managementmodule”, “stream data content analysis module”, “stream data transfermodule”, and “time related information generation module”.

[0300] Note that the “reception time management module” is comprised ofdemodulator (demodulation unit) 422, reception information selector 423,multiplexed information demultiplexer 425, STB controller 404, and soon. The “reception time management module” receives digital TV broadcastvia satellite antenna 421, and records reception times in units oftransport packets in the received broadcast information.

[0301] The “stream data content analysis module” is comprised ofmultiplexed information demultiplexer 425, STB controller 404, and soon. This “stream data content analysis module” analyzes the contents ofthe received stream data, and extracts I-, B-, and P-picture positionsand/or PTS values.

[0302] The “stream data transfer module” is comprised of multiplexedinformation demultiplexer 425, reception information selector 423, STBcontroller 404, data transfer interface 420, and so on. This “streamdata transfer module” transfers the stream data to optical disc device415 while holding differential reception time intervals in units oftransport packets.

[0303] The “time related information generation module” is comprised ofmultiplexed information demultiplexer 425, STB controller 404, datatransfer interface 420, and so on. The “time related informationgeneration module” generates relationship information between receptiontime (time stamp) information recorded by the “reception time managementmodule” and display time information (PTS value and/or the number offields) extracted by the “stream data content analysis module”.

[0304] The process upon recording stream data in the apparatus shown inFIG. 11 will be explained below. As shown in FIG. 5(c), a plurality ofpieces of program information are time-divisionally multiplexed in asingle transponder. Reception information selector 423 extracts atransport packet of only a specific program from that information, asshown in FIG. 5(d).

[0305] The “reception time management unit” temporarily saves therequired program information in memory 426 of multiplexed informationdemultiplexer 425. At the same time, the unit measures reception timesin units of transport packets, and appends the measurement values to therespective transport packets as time stamps, as shown in FIG. 5(d). Theappended time stamp information is recorded in memory 426.

[0306] The “stream data content analysis unit” analyzes information inthe transport packets recorded in memory 426. More specifically, eachpicture boundary position is extracted from the transport packetsequence, and playback time stamp (PTS) information is also extracted.As described above, there are two different picture boundary positionextraction methods, and one of these methods is selected depending onthe contents of stream data. Then, the stream data temporarily saved inmemory 426 is recorded on information storage medium 201.

[0307] Time map information 252 is used to compute a correspondingstream block when STB unit 416 designates a time stamp value as theplayback start position. This time map information 252 is recorded as apart of stream object information 243 in STREAM.IFO 105 as a managementinformation recording area for stream data, as shown in FIG. 3(e) to(h).

[0308] As shown in FIG. 3(i), time map information 252 records only timestamp differential time information of each stream block. Hence, thevalues of time differences of stream blocks in time map information 252are summed up in each of stream object information 242 or 243, andcomparison must be made to check if this summed-up value has reached thetime stamp time designated by STB unit 416. Based on the comparisonresult, the position of a stream block in a stream object, which blockincludes the time stamp value that matches the time designated by STBunit 416, is detected.

[0309] An embodiment that pertains to partial erase of stream dataalready recorded on information storage medium 201 will be explainedbelow.

[0310] In the stream data recording/playback apparatus, theaforementioned partial erase process is controlled by STB controller404, and process implementation is done especially by a sequentialprogram named a stream data partial erase controller in that controller404.

[0311] STB controller 404 in FIG. 11 reads information of STREAM.IFO 105that describes management information (STRI) which pertains to streamdata before partial erase, and temporarily saves that information inwork RAM memory 407. Upon completion of the partial erase process,sectors to be partially erased are excluded from STREAM.VRO (orSR_TRANS.SRO) 106 in FIG. 2. After that, the management information STRIincluding SOBI and SCI) is changed to the contents shown in FIG. 9(l),thus rewriting data in STREAM.IFO 105 in FIG. 2.

[0312] The access method “which corresponds to video compression byMPEG, and considers the decode timing of the decoder” will be explainedbelow as that to stream data playback of which is to begin in a streamobject.

[0313] In an embodiment of the present invention, stream data istransferred from STB unit 416 in isochronous mode and, at the same time,I-picture information is transferred in real time. The transferredinformation is recorded in the STREAM.VRO 106 file that records streamdata, as shown in FIG. 1(a). In an embodiment of the present invention,this information is also recorded in STREAM.IFO 105 that recordsmanagement information of stream data.

[0314] When STB unit 416 shown in FIG. 11 is to play back and display,e.g., B-picture information 504 in FIG. 7, it informs optical discdevice 415 of the value of time stamp la corresponding to transportpacket la which is located at the head position of I-picture information501 located immediately before B-picture information 504.

[0315] Optical disc device 415 detects the sector position from whichplayback is to start using information of time map information 252 withthe structure shown in FIG. 1 or 3, accesses a predetermined position oninformation storage medium 201, and transfers stream data to be playedback to STB unit 416. Decoder unit 402 in STB unit 416 begins to decodefrom I-picture information 501, and starts display from designatedB-picture information 504.

[0316] Transport packet 41 d (FIG. 7) that records start information ofB-picture information 504 records, in its transport packet header 311,information of playback time stamp (presentation time stamp) PTS 304which indicates the display start time, as shown in FIG. 5 (a) and (b).Decoder unit 402 reads this PTS 305 to set the playback start time.

[0317] The method of extracting the I-picture position by decoder unit402 in FIG. 11 has been explained. However, some digital TV broadcaststation may send each picture position information in the process oftransmission. Each picture position information already recorded in theprocess of transmission will be explained below.

[0318] In an embodiment of the present invention, the stream blockboundary positions set upon initial recording are maintained even forstream data after partial erase, while the remaining portion isredefined in a new stream object to have the partially erased portion asa boundary. In this case, the first and last stream blocks in a streamobject often have sizes smaller than those of other stream blocks. Forthis reason, time map information 252 records individual stream blocksize information, as shown in FIG. 1 (l) or FIG. 3 (i).

[0319] This embodiment is not limited to the aforementioned specificexample. For example, only the first stream block size information andlast stream block size information may be recorded, and only commonstream block size information may be recorded for other stream blocks.

[0320]FIG. 12 is a flow chart for explaining the processes of alignmentbetween an application packet and stream object and a padding process atthe end of a stream object when information recording of a bitstream isdone by the system shown in FIG. 11.

[0321] In optical disc device (streamer) 415 in FIG. 11, a bitstream(the contents of a transport packet) to be recorded is distributed toapplication packet areas in a stuffing packet (step ST10).

[0322] The first byte (A) of an application time stamp (ATS) of thefirst application packet is compared with the start portion (B) of anapplication packet area in the first stream packet which is located atthe start portion of a stream object (SOB) that records a bitstream(step ST12).

[0323] If the first byte (A) of the ATS does not match the start portion(B) of the application packet area in the first stream packet (NO instep ST14), for example, a required number of stuffing bytes areinserted in the stream packet to align the first byte (A) with the startportion (B) (step ST16).

[0324] If the first byte (A) of the ATS matches the start portion (B) ofthe application packet area in the first stream packet (YES in stepST14), or after the first byte (A) and start portion (B) are aligned, itis checked if a blank for one stream packet (one sector) or more ispresent between the end of the last application packet (C) containingactual data of the bitstream to be recorded, and the end (D) of the SOBthat records the bitstream (step ST18).

[0325] If the blank for one stream packet (one sector) or more ispresent between the end of the application packet (C) and the end (D) ofthe SOB (YES in step ST18), this blank is stuffed with one or morestuffing packets including one ATS (step ST20).

[0326] If no blank is present between the end of the application packet(C) and the end (D) of the SOB (NO in step ST18), or after the blankbetween the end of the application packet (C) and the end (D) of the SOBis stuffed with stuffing packets, a group of one or more applicationpackets (that can contain stuffing packets or a stuffing byte area asneeded) containing the contents of the bitstream to be recorded isrecorded on information medium 201 (step ST22).

[0327] After that, a write is made to the management information (STRI)in correspondence with the recorded information (step ST24).

[0328] In the recording step ST22, the following process is done asneeded.

[0329] (10) When a blank portion is present at the end of an applicationpacket area, a stuffing area (padding area 37 in FIG. 5 (h) or FIG. 19(j)) consisting of a predetermined number of bytes is assured in thisblank portion (without any time stamp).

[0330] In the recording steps ST22 and ST24, the following processes aredone as needed.

[0331] (11) Stream data (SOB) is formed by a plurality of data units(SOBU#α, . . . , SOBU#λ in FIG. 8 (a)), each data unit (SOBU#α, . . . ,SOBU#λ) is formed by one or more data packets (TP/AP in FIG. 8 (b)) thatrecord predetermined time stamp (TMS) information, and

[0332] the time difference value (rounded value in FIG. 8(c) and (d))corresponding to at least the difference between the first time stamp(TMS 1 a) recorded in the first data unit (SOBU#α) and the second timestamp (TMS 33 a) recorded in the second data unit (SOBU#β) of aplurality of the data units (SOBU#α, . . . , SOBU#λ) is recorded in themanagement area (STRI or STREAM.IFO/SR_MANGR.IFO).

[0333] (12) One or more pieces of cell (FIG. 18) information arerecorded in stream data (SOB),

[0334] program chain (PGC) information (PGCI in FIG. 3(f) or 13) thatdescribes a group of one or more cells is recorded in the managementarea (STRI or STREAM.IFO/SR_MANGR.IFO), and

[0335] entry point (EP) information (SC_EPI) that can be used as amarker of a skip position upon partially skipping the recorded contentsof the stream data (SOB) in playback is recorded in the managementinformation (STRI).

[0336] (13) Stream object general information (SOBI_GI in FIG. 7 (d) or15) including at least one of recording time information (SOB_REC_TM) ofstream data (SOB), the data packet arrival time (SOB_S_APAT) of thestart portion of the stream data (SOB), and the data packet arrival time(SOB_E_APAT) of the end portion of the stream data (SOB) is written inmanagement information (STRI).

[0337]FIG. 13 is a view for explaining the internal data structure ofmanagement information (STREAM.IFO or SR_MANGR.IFO in FIG. 2 or FIG. 3)of the streamer.

[0338] STREAM.IFO (SR_MANGR.IFO) 105 as management information(navigation data) shown in FIG. 2 or FIG. 3(e) includes streamerinformation STRI, as shown in FIG. 13.

[0339] This streamer information STRI is comprised of streamer videomanager information STR_VMGI, stream file information table SFIT,original PGC information ORG_PGCI (more generally, PGC informationPGCI#i), user-defined PGC information table UD_PGCIT, text data managerTXTDT_MG, and application private data manager APDT_MG, as shown in FIG.3 (f) or FIG. 13.

[0340] Streamer video manager STR_VMGI includes video managerinformation management information VTSI_MAT that describes managementinformation which pertains to STRI and STR_VMGI, and the like, and aplay list search pointer table (PL_SRPT) that describes search pointers.used to search for a play list in the stream, as shown in FIG. 13.

[0341] Note that the play list is a list of portions of a program. Withthis play list, the user can define an arbitrary playback sequence (forthe contents of a program).

[0342] Stream file information table SFIT includes all navigation datathat directly pertain to the streamer operation. Details of stream fileinformation table SFIT will be explained later with reference to FIG.15.

[0343] Original PGC information ORG_PGCI is a portion that describesinformation which pertains to an original PGC (ORG_PGC). ORG_PGCindicates navigation data which describes a program set. ORG_PGC is achain of programs, and includes stream data recorded in a “.SRO” file(SR_TRANS.SRO 106 in FIG. 2) shown in FIG. 2 or FIG. 18 to be describedlater Note that the program set indicates the entire recorded contents(all programs) of information storage medium 201. Upon playing back theprogram set, the same playback order as the recording order of programsis used except for a case wherein an arbitrary program has been edited,and the playback order of original recording has been changed. Thisprogram set corresponds to a data structure called an original PGC(ORG_PGC).

[0344] Also, a program is a logical unit of recorded contents, which isrecognized by the user or is defined by the user. A program in theprogram set is made up of one or more original cells. The program isdefined within only the original PGC.

[0345] Furthermore, a cell is a data structure indicating a portion of aprogram. A cell in the original PGC is called an “original cell”, and acell in a user-defined PGC (to be described later) is called a“user-defined cell”.

[0346] Each program in the program set consists of at least one originalcell. A portion of a program in each play list consists of at least oneuser-defined cell.

[0347] On the other hand, only a stream cell (SC) is defined in thestreamer. Each stream cell looks up a portion of the recorded bitstream.In an embodiment of the present invention, a “cell” means a “streamcell” unless otherwise specified.

[0348] Note that a program chain (PGC) is a generic unit. In an originalPGC, PGC indicates a chain of programs corresponding to a program set.On the other hand, in a user-defined PGC, PGC indicates a chain ofportions of programs corresponding to a play list.

[0349] A user-defined PGC indicating a chain of portions of programsincludes navigation data alone. A portion of each program looks upstream data belonging to the original PGC.

[0350] User-defined PGC information table UD_PGCIT in FIG. 13 caninclude user-defined PGC information table information UD_PGCITI, one ormore user-defined PGC search pointers UD_PGC_SRP#n, and one or morepieces of user-defined PGC information UD_PGCI#n.

[0351] User-defined PGC information table information UD_PGCITI includesUD_PGC_SRP_Ns indicating the number of user-defined PGC search pointersUD_PGC_SRP, and UD_PGCIT_EA indicating the end address of user-definedPGC information table UD_PGCIT (not shown).

[0352] The number of “UD_PGC_SRP”s indicated by UD_PGC_SRP_Ns is thesame as the number of pieces of user-defined PGC information (UD_PGCI),and is also the same as the number of user-defined PGCs (UD_PGC). Themaximum value of UD_PGC_SRP_Ns is “99”.

[0353] UD_PGCIT_EA describes the end address of UD_PGCIT of interest bythe relative number of bytes (F_RBN) from the first byte of thatUD_PGCIT.

[0354] Note that F_RBN indicates the relative number of bytes from thefirst byte of the defined field, and starts from zero.

[0355] PGCI#i that generally expresses original PGC information ORG_PGCIor user-defined PGC information UD_PGCI in user-defined PGC informationtable UD_PGCIT will be described later with reference to FIG. 14.

[0356] Text data manager TXTDT_MG in FIG. 13 is supplementary textinformation. This TXTDT_MG can be stored in the play list and programtogether with primary text information PRM_TXTI shown in FIG. 14.

[0357] Application private data manager APDT_MG in FIG. 13 can includeapplication private data manager general information APDT_GI, one ormore APDT search pointers APDT_SRP#n, and one or more APDT areasAPADTA#n (not shown).

[0358] Note that application private data APDT is a conceptual area thatallows an application device connected to the streamer to storearbitrary non-real time information (more desired information inaddition to real-time stream data).

[0359]FIG. 14 is a view for explaining the internal data structure ofPGC Information (ORG_PGCI/UD_PGCIT in FIG. 3 or PGCI#i in FIG. 13). PGCinformation PGCI#i in FIG. 14 generally expresses original PGCinformation ORG_PGCI or user-defined PGC information UD_PGCI inuser-defined PGC information table UD_PGCIT in FIG. 13.

[0360] As shown in FIG. 14, PGC information PGCI#i is made up of PGCgeneral information PGC_GI, one or more pieces of program informationPGI#m, one or more stream cell information search pointers SCI_SRP#n,and one or more pieces of stream cell information SCI#n.

[0361] PGC general information PGC_GI includes the number PG_Ns ofprograms, and the number SCI_SRP_Ns of stream cell information searchpointers SCI_SRP.

[0362] Each program information PGI (e.g., PGI#1) includes program typePG_TY, the number C_Ns of cells in the program of interest, primary textinformation PRM_TXTI of the program of interest, and search pointernumber IT_TXT_SRPN of item text.

[0363] Note that program type PG_TY includes information indicating thestate of the program of interest. Especially, program type PG_TYincludes a flag indicating if that program is protected from an eraseerror, i.e., a protect flag.

[0364] When this protect flag is “0b”, the program of interest is notprotected; when it is “1b”, the program is protected.

[0365] The number C_Ns of cells indicates the number of cells in theprogram of interest. In all the programs and cells in a PGC, cells(tacitly) append themselves to each program in their ascending order.

[0366] For example, if program #1 in a given PGC has C_Ns=1, and program#2 has C_Ns=2, first stream cell information SCI of that PGC is appendedto program #1, and the second SCI and third SCI are appended to program#2.

[0367] Primary text information PRM_TXTI describes text informationhaving a single common character set (ISO/IEC646:1983 (ASCII code)) toallow use of information storage medium (DVD-RAM disc) 201 anywhere inthe world.

[0368] Item text search pointer number IT_TXT_SRPN describes a searchpointer number corresponding to item text (text data corresponding tothe program of interest) IT_TXT. If the program of interest has no itemtext, IT_TXT_SRPN is set at “0000h”.

[0369] Each stream cell information search pointer SCI _SRP (e.g., SCI_SRP#1) includes SCI _SA indicating the start address of correspondingstream cell information SCI. This SCI_SA is described as the relativenumber of bytes (F_RBN) from the first byte of PGCI.

[0370] Each stream cell information SCI (e.g., SCI#l) is made up ofstream cell general information SC_GI and one or more pieces of streamcell entry point information SC_EPI#n.

[0371] Stream cell general information SC_GI includes cell type C_TYincluding flag TE indicating a temporary erase (TE) state, the numberSC_EPI_Ns of pieces of entry point information of a stream cell, streamobject number SOB_N, stream cell start APAT (SC_S_APAT shown in FIG. 9),stream cell end APAT (SC_E_APAT shown in FIG. 9), erase start APAT(ERA_S_APAT) indicating start APAT of a temporary erase cell if thatcell is in the temporary erase state (TE=01b), and erase end APAT(ERA_E_APAT) indicating end APAT of a temporary erase cell if that cellis in the temporary erase state (TE=10b).

[0372] Cell type C_TY describes the type and temporary erase state ofthe stream cell of interest.

[0373] More specifically, cell type C_TY1=“010b” is described in thetype of all stream cells (with this C_TYl=“010b”, a stream cell can bedistinguished from other cells).

[0374] On the other hand, if flag TE is “00b ”, it indicates that thecell of interest is in a normal state; if flag TE is “01b” or “10b”,that cell is in a temporary erase state.

[0375] Flag TE=“01b” indicates that the cell of interest (cell in thetemporary erase state) starts from a position after the firstapplication packet that starts within a SOBU, and comes to an end at aposition before the last application packet in that SOBU.

[0376] On the other hand, flag TE=“10b” indicates that the cell ofinterest (cell in the temporary erase state) includes at least one SOBUboundary (the first or last application packets starts within thatSOBU).

[0377] Note that a protect flag of a program and TE flag of a cell inthat program cannot be set at the same time. Therefore,

[0378] (a) none of cells in a program in the protect state can be set inthe temporary erase state; and

[0379] (b) a program including one or more cells in the temporary erasestate cannot be set in the protect state.

[0380] The number SC_EPI_Ns of pieces of entry point information of astream cell describes the number of pieces of stream cell entry pointinformation included in stream cell information SCI of interest.

[0381] Each stream cell entry point information SC_EPI (e.g., SC_EPI#1)in FIG. 14 includes two types (types A and B).

[0382] SC_EPI of type A includes entry point type EP_TY and entry pointapplication packet arrival time EP_APAT. Type A is set by entry pointtype EP_TYI=“00b”.

[0383] SC_EPI of type B includes primary text information PRM_TXTI inaddition to EP_TY and EP_APAT of type A. Type B is indicated by entrypoint type EP_TY1=“01b”.

[0384] As a tool for skipping a portion of the recorded contents in anarbitrary stream cell, an entry point can be used. All entry points canbe specified by application packet arrival times (APAT). This APAT canspecify the data output start position.

[0385] Stream object number SOB N describes the number of an SOB thatthe cell of interest looks up.

[0386] Stream cell start APAT (SC_S_APAT) describes start APAT of thecell of interest.

[0387] Stream cell end APAT (SC_E_APAT) describes end APAT of the cellof interest.

[0388] Erase start APAT (ERA_S_APAT) describes the arrival time (APAT)of the first application packet that starts within the first SOBU, thehead position of which is included in a given temporary erase cell (TEfield of its C_TY is “10b”) including at least one SOBU boundary, inthat temporary erase cell.

[0389] Erase end APAT (ERA_E_APAT) describes the arrival time (APAT) ofthe first application packet that starts within an SOBU including anapplication packet which immediately follows a temporary erase cell (TEfield of its C_TY is “10b”) including at least one SOBU boundary, inthat temporary erase cell.

[0390]FIG. 15 is a view for explaining the internal data structure ofthe stream file information table (SFIT).

[0391] As shown in FIG. 15, stream file information table SFIT is madeup of stream file information table information SFITI, one or morepieces of stream object stream information SOB_STI#n, and stream fileinformation SFI.

[0392] Stream file information table information SFITI consists of thenumber SFI_Ns of pieces of stream file information on informationstorage medium (DVD-RAM disc) 201, the number SOB_STI_Ns of pieces ofstream object stream information that follow SFITI, end address SFIT_EAof SFIT, and start address SFI_SA of SFI.

[0393] SFIT_EA describes the end address of SFIT by the relative numberof bytes (F_RBN) from the first byte of SFIT.

[0394] SFI_SA describes the start address of SFI by the relative numberof bytes (F_RBN) from the first byte of SFIT.

[0395] Stream object stream information SOB_STI includes three differentparameters. Each parameter can assume a value unique to individualbitstream recording. However, these parameter sets can have equal valuesin most bitstream recording. Therefore, SOB_STI is stored in a tableindependently from the table of stream object information (SOBI), andsome stream objects (SOB) are allowed to share identical SOB_STI (i.e.,point to identical SOB_STI). Therefore, the number of pieces of SOB_STIis generally larger than the number of SOBs.

[0396] Each stream object stream information SOB_STI (e.g., SOB_STI#1)in FIG. 15 includes application packet size AP_SIZ, the numberSERV_ID_Ns of service IDs, service ID (SERV_IDs), and application packetdevice unique ID (AP_DEV_UID).

[0397] AP_SIZ describes the application packet size by the byte lengthof a packet in a bitstream transferred from an application device to thestreamer.

[0398] In the DVD streamer, the application packet size is fixed in eachbitstream recording. For this reason, if the application packet sizechanges in each recording free from any interrupt, the current streamobject (current SOB) comes to an end there, and a new stream object (newSOB) starts with new AP_SIZ. In this case, the current and new SOBsbelong to an identical program in original PGC information (ORG_PGCI).

[0399] SERV_ID_Ns describes the number of service IDs included in thesubsequent parameter.

[0400] SERV_IDs describes a list of service IDs in an arbitrary order.

[0401] AP_DEV_UID describes a unique device ID unique to an applicationdevice that supplies the recorded bitstream.

[0402] As shown in FIG. 15, stream file information SFI is comprised ofstream file general information SF_GI, one or more stream objectinformation (SOB information) search pointers (SOBI_SRP) #n, and one ormore pieces of SOB information (SOBI) #n.

[0403] Stream file general information SF_GI includes the number SOBI_Nsof pieces of SOBI, and sector size SOBU_SIZ per SOBU.

[0404] SOBU_SIZ describes the SOBU size using the number of sectors, andthis size is fixed at 32 (32 sectors=64k bites). This means that thefirst entry is associated with an application packet included in thefirst 32 sectors of an SOB. Likewise, the second entry is associatedwith an application packet included in the next 32 sectors. The sameapplies to the third and subsequent entries.

[0405] Each SOB information search pointer (e.g., SOBI_SRP#1) includesstart address SOBI_SA of SOBI. This SOBI_SA describes the start addressof the associated SOBI using the relative number of bytes (F_RBN) fromthe first byte of stream file information SFI.

[0406] Each SOB information (e.g., SOBI#1) is made up of stream objectgeneral information SOB_GI, time map information MAPL, and access unitdata AUD (option).

[0407] Stream object general information SOB_GI includes stream objecttype SOB_TY, stream object recording time SOB_REC_TM, stream objectstream information number SOB_STI_N, access unit data flag AUD_FLAGS,stream object start application packet arrival time SOB_S_APAT, streamobject end application packet arrival time SOB_E_APAT, start streamobject unit SOB_S_SOBU of the stream object of interest, and the numberMAPL_ENT_Ns of entries in time map information.

[0408] Stream object type SOB_TY is a field that describes bitsindicating the temporary erase state (TE state) and/or bits of the copygeneration management system.

[0409] Stream object recording time SOB_REC_TM describes the recordingtime of the associated stream object (SOB).

[0410] Stream object stream information number SOB_STI_N describes anindex of valid SOB_STI for the stream object of interest.

[0411] Access unit data flag AUD_FLAGS describes whether. or not accessunit data (AUD) is present for the stream object of interest, and thetype of access unit data if it is present.

[0412] If access unit data (AUD) is present, AUD FLAGS describes someproperties of AUD.

[0413] The access unit data (AUD) itself consists of access unit generalinformation AU_GI, access unit end map AUEM, and playback time stamplist PTSL, as shown in FIG. 15.

[0414] Access unit general information AU_GI includes AU_Ns indicatingthe number of access units described in correspondence with the SOB ofinterest, and access unit start map AUSM indicating an SOBU that belongsto the SOB of interest and includes an access unit.

[0415] Access unit end map AUEM is a bit array having the same length asthat of AUSM (if it is present), and indicates an SOBU that includes theterminal end of a bitstream segment appended to the access unit of theSOB of interest.

[0416] Playback time stamp list PTSL is a list of playback time stampsof all access units that belong to the SOB of interest. One PTSL elementincluded in this list includes a playback time stamp (PTS) of thecorresponding access unit.

[0417] Note that the access unit (AU) indicates an arbitrary single,continuous portion of the recorded bitstream, and is suitable forindividual playback. For example, in an audio/video bitstream, an accessunit corresponds to I-picture of MPEG.

[0418] The contents of SOB_GI will be explained again.

[0419] AUD_FLAGS includes flag RTAU_FLG, flag AUD_FLG, flag AUEM_FLG,and flag PTSL_FLG.

[0420] When flag RTAU_FLG is 0b, it indicates that no access unit flagis present in real-time data of the SOB of interest.

[0421] When flag RTAU_FLG is 1b, it indicates that AU. flags (AU_START,AU_END) described in the application header extension shown in FIG.10(d) can be present in real-time data of the SOB of interest. Thisstate is also allowed when AUD_FLG (to be described below) is 0b.

[0422] When flag AUD_FLG is 0b, it indicates that no access unit data(AUD) is present for the SOB of interest.

[0423] When flag AUD_FLG is 1b, it indicates that access unit data (AUD)can be present for the SOB of interest.

[0424] When flag AUEM_FLG is 0b, it indicates that no AUEM is present inthe SOB of interest.

[0425] When flag AUEM_FLG is 1b, it indicates that AUEM is present inthe SOB of interest.

[0426] When flag PTSL_FLG is 0b, it indicates that no PTSL is present inthe SOB of interest.

[0427] When flag PTSL_FLG is 1b, it indicates that PTSL is present inthe SOB of interest.

[0428] SOB_S_APAT describes the start application packet arrival time ofa stream object. That is, SOB_S_APAT indicates the arrival time of thefirst application packet that belongs to the SOB of interest.

[0429] This packet arrival time (PAT) is divided into two fields, i.e.,a basic field and extended field. The basic field is called a 90-kHzunit value, and the extended field indicates a less significant valuemeasured at 27 MHz.

[0430] SOB_E_APAT describes the end application packet arrival time of astream object. That is, SOB_E_APAT indicates the arrival time of thelast application packet that belongs to the SOB of interest.

[0431] SOB_S_SOBU describes the start stream object unit of the streamobject of interest. That is, SOB_S_SOBU indicates an SOBU including thestart portion of the start application packet of the stream object.

[0432] MAPL_ENT_Ns describes the number of entries in time mapinformation (MAPL) that follows SOBI_GI.

[0433] Time map information MAPL has contents corresponding to time mapinformation 252 shown in FIG. 3(h).

[0434] One of relevancies between the contents of FIGS. 13 and 15 issummarized as follows:

[0435] Streamer information STRI included in management information 105contains stream file information table SFIT that manages stream objectSOB which forms the contents of stream data. This SFIT includes streamobject information SOBI that manages SOB. This SOBI includes access unitgeneral information AU_GI including management information (access unitstart map AUSM), and management information (PTSL).

[0436] Note that the management information (ATS or AUSM) containsinformation used upon transferring stream data, and the managementinformation (PTS or SC_S_APAT) contains information used when the streamdata is displayed.

[0437]FIG. 16 is a view exemplifying the correspondence between theaccess unit start map (AUSM) and stream object unit (SOBU).

[0438] As shown in FIG. 16, bit “1”, of AUSM indicates that the accessunit (AU) is included in the corresponding SOBU.

[0439] Assume that AUSM_pos(i) represents the i-th (1≦i≦AU_NS) bitposition where a bit is set in AUSM. Then, the position of access unitAU is as follows.

[0440] (1) If SOBU#i indicated by AUSM_pos(i) contains one or more startAUs (described using AU-START and AU_END marks in a stream (ifavailable)), AUSM_pos(i) is assigned to the first AU that starts withinSOBU#i. Note that SOBU#i is laid out in SOBUs described usingAUSM_pos(i) and AUEM_pos(i) (if AUEM is available).

[0441] (2) AU comes to an end at the AU_END mark that appears firstafter this AU starts, and comes to an end in the last SOBU indicated bythe assigned AUEM element (if AUEM is available).

[0442] In any access unit data, two or more accessible access unitscannot be described per SOBU in an SOB.

[0443]FIG. 17 is a view exemplifying the correspondence between theaccess unit start map (AUSM) and access unit end map (AUEM), and streamobject unit (SOBU).

[0444] AUEM is a bit array having the same length as the AUSM (ifavailable). The bits of AUEM indicate a SOBU that includes the end of abitstream segment appended to the access unit of the SOB of interest.

[0445] The number of bits set in AUEM matches that set in AUSM. That is,the set bits in AUSM have those set in AUEM in correspondence with eachother.

[0446] Assume that AUSM_pos(i) represents the i-th (1≦i≦AU_Ns) bitposition where a bit is set in AUSM, and AUEM_pos(i) the i-th(1≦i≦AU_Ns) bit position where a bit is set in AUEM. In this case, thefollowing relations hold:

[0447] (1) 1≦AUSM_pos(i)≦AUEM_pos(i)≦MAPL_ENT_Ns;

[0448] (2) AUSM_pos(i+1)>AUEM_pos(i);

[0449] (3) If i==AU_NS or AUSM_pos(i+1)>1 AUEM_pos(i), AU#i comes to anend in SOBU#[AUEM_pos(i)] (1≦i≦AU_Ns); and

[0450] (4) If AUSM_pos(i+1)==1+AUEM_pos(i), AU#i comes to an end inSOBU#[AUEM_pos(i)]. Or it comes to an end at the position ofSOBU#[1+AUEM_pos(i)]==SOBU#[AUSM_pos(i+1)]. That is, AU#i comes to anend at the beginning of AU#i+1 in SOBU (1≦i≦AU_Ns).

[0451]FIG. 18 is a view showing an example of the relationship definedbetween cells designated by an original or user-defined PGC, and SOBUscorresponding to these cells via time map information.

[0452] A user-defined PGC does not contain its own SOB, but looks up anSOB in an original PGC. Therefore, the user-defined PGC can be describedusing only PGC information. This means that an arbitrary playbacksequence can be implemented without modifying SOB data.

[0453] The user-defined PGC does not contain any program, and is made upof a chain of cells corresponding to portions of programs in theoriginal PGC.

[0454]FIG. 18 shows an example of such user-defined PGC. In thisexample, user-defined PGC#n is formed so that a cell in the PGC looks upan SOB in an original PGC.

[0455] Referring to FIG. 18, PGC#n has four cells #1 to #4. Of thesecells, two cells look up SOB#1, and the remaining two cells look upSOB#2.

[0456] The solid arrows from cells in the user-defined PGC to theoriginal PGC (time map information of an SOBI) indicate the playbackperiods of those cells. The cell playback order in the user-defined PGCbecomes quite different from that in the original PGC.

[0457] Playback of an arbitrary SOB and its SOBUs is specified by startAPAT (S_APAT) and end APAT (E_APAT) in FIG. 18.

[0458] S_APAT of the SOB or SOBU is defined in association with a timestamp recorded in the payload (see FIG. 5(b)) of a stream pack of theSOB of interest.

[0459] During SOB recording, each incoming application packet isappended with a time stamp by the local clock reference in the streamer.This is the application packet arrival time (APAT).

[0460] APAT of the start application packet of the SOB is stored asSOB_S_APAT. Four least significant bytes of all APATs are fixed inadvance for a corresponding application packet in a “_.SRO” file.

[0461] In order to play back data of the SOB or SOBU, the internalreference clock of the streamer is set at an SCR value, and clocks arethen automatically counted. This SCR value is described in the firststream pack (pack header) from which playback begins. Based on theclocks, all subsequent application packets are played back and outputfrom the SOB or SOBU.

[0462] When an arbitrary stream cell (SC) defines stream cell start APAT(SC_S_APAT) that has an arbitrary value between SOB_S_APAT andSOB_E_APAT of an SOB that SC points to, an address used to find out anSOBU that includes an application packet with a desired APAT isrequired.

[0463] The number of stream packs per SOBU is constant, but theintervals of arrival times captured by SOBUs are flexible. Therefore,each SOB has time map information that describes the arrival timeintervals of its SOBUs. That is, the address system implemented by timemap information converts arbitrary APAT into a relative logical blockaddress in the file to point to an SOBU that contains a desiredapplication packet.

[0464] Entry points (EP#i, EP#k) exemplified in FIG. 18 can be specifiedby application packet arrival times (APAT) each indicating a data outputstart position. The application packet arrival time of this entry pointis indicated by EP_APAT in FIG. 14.

[0465] Using the entry point, upon playback from, e.g., SOBU#1 of cell#1, playback can start from the designated position of SOBU#i whileskipping SOBU#2 to SOBU#(i-1).

[0466]FIG. 19 is a view for explaining the data structure of stream dataaccording to another embodiment of the present invention.

[0467] Stream data recorded on an information storage medium such as aDVD-RAM disc or the like are combined as stream objects (SOB) in unitsof contents of video information in stream data. Each SOB is formed ofstream data obtained by single real-time, continuous recording.

[0468]FIG. 19(f) shows one SOB#A•298 of one or more stream objects. Whenthis stream data is recorded on a DVD-RAM disc, each data is recordedusing 2,048-byte sectors as minimum units. Furthermore, 16 sectors formone ECC block, and in one ECC block, data are interleaved (the order ofdata is re-arranged) and a correction code for error correction isappended.

[0469] In this embodiment, a stream block is formed by one or aplurality of ECC blocks as a unit, and stream information is recorded orpartially erased in units of stream blocks.

[0470] In this embodiment, the number of ECC blocks that form a streamblock can be determined in accordance with the transfer rate of streamdata to be transferred. For example, in an example shown in FIG. 19(e),stream block #1 is formed by two ECC blocks #α and #β, and stream block#2 is formed by three ECC blocks #γ, #67, and #ε. A DVD streamer formsone stream block (stream object unit SOBU) using two ECC blocks (32sectors).

[0471] Each ECC block is made up of 16 sectors, as shown in FIG. 19(d).Therefore, as can be seen from FIG. 19(d) and (e), stream block (orSOBU) #1 made up of two ECC blocks corresponds to 32 sectors (sectorsNo. 0 to No. 31).

[0472] More specifically, if one sector=2k bytes, a stream block (SOBU)has a fixed size of 64k bites (32 sectors) upon practicing the presentinvention.

[0473] The contents of each sector correspond to a stream pack (seeFIGS. 5, 6, and 10 for details). For example, a stream packcorresponding to sector No. 0 (FIG. 19(d)) includes pack header 1 x, PESheader 6 x, stream block header 11 x, and data area 21 x, as shown inFIG. 19(c). On the other hand, a stream pack corresponding to sector No.1 (FIG. 19(d)) includes pack header 2 x, PES header 7 x, sector dataheader 12 x, and data area 22 x, as shown in FIG. 19(c).

[0474] Data area 21 x in FIG. 19(c) includes a sequence of pairs of timestamps and transport packets (time stamp a, transport packet a, timestamp b, . . . , transport packet d), as shown in FIG. 19(b). Likewise,data area 22 x includes another sequence of pairs of time stamps andtransport packets. On the other hand, trailing-side data area 23 xincludes transport packet f, end code 31 x, and padding area 36 x, asshown in FIG. 19(b).

[0475] A plurality of pairs of time stamps and transport packets shownin FIG. 19(b) form a bitstream having a sequence shown in FIG. 19(a).

[0476] Stream block #1 (FIG. 19(e)) preceding SOB#A•298 (FIG. 19(f)) hasa data structure shown in FIG. 19(d) to (b), but the data structure ofstream block #2 (FIG. 19(g)) succeeding SOB#A•298 is as follows.

[0477] That is, trailing-side sector No. 78 (FIG. 19(h)) of end ECCblock #ε of stream block #2 includes pack header 3 x, PES header 8 x,sector data header 13 x, and data area 24 x, as shown in FIG. 19(i).Also, last sector No. 79 (FIG. 19(h)) of ECC block #ε includes packheader 4 x and padding packet 40 x, as shown in FIG. 19(i).

[0478] Data area 24 x of sector No. 78 includes transport packet z, endcode 32 x, and padding area 37 x, as shown in FIG. 19(j). Padding packet40x of last sector No. 79 includes PES header 9 x and padding area 38 x,as shown in FIG. 19(j).

[0479] Note that the contents of padding area 37 x can be comprised ofone or more pairs of time stamps and packets, and a stuffing area with areserved number of bytes (the stuffing area is appended with no timestamp), as shown in FIG. 5(h). In this case, no stream data is recordedin the stuffing area.

[0480] On the other hand, the contents of padding area 38 x can becomprised of an application packet area including stuffing packets (onlythe first one is appended with application time stamp ATS), as shown inFIG. 6(i) and (j).

[0481] The present invention can also adopt data structures with thefollowing features:

[0482] A) A data structure in which pack headers/packet headers areprovided in units of sectors/stream packs, and information required foreach sector/stream pack is recorded in a pack header/packet header (seeFIG. 1(a) to (c), FIG. 5(a) and (b), and FIG. 10(a) to (g)).

[0483] B) A data structure that records time information which pertainsto the time interval at which respective transport packets/applicationpackets are transferred to the decoder on an information storage mediumas time stamp information together with the transportpackets/application packets (see FIG. 1(k) to (m) and FIGS. 5 to 10).

[0484] C) A data structure that packs and records time stamps andtransport packets/application packets at locations other than packheaders/packet headers in a sector/stream pack. A data structure thatallocates and records one of a time stamp and transportpacket/application packet to a position in the neighboring sector/streampack when the division (or cutting portion) of the time stamp or that ofstream data recorded in units of transport packets/application packetsis different from the boundary position of the sector/stream pack (seeFIG. 1(d) to (g) and FIG. 5(e) to (j)).

[0485] D) A data structure which defines a group of videos obtained bysingle recording of the user or the like as a stream object (SOB), anddefines an area after the position of the last transportpacket/application packet as a padding area only within a sector/streampack of interest when the position of the last transportpacket/application packet (the position of the last transportpacket/application packet in a single stream object) recorded on aninformation storage medium in single video recording is different fromthe boundary position of a sector/stream pack (see FIG. 1(g) and (k),FIG. 6(g) to (j), and FIG. 19(j)).

[0486] E) A data structure which provides, onto an information storagemedium, a management file (STREAM.IFO or RTR.IFO) that manages streamdata in a file (STREAM.VRO or RTR_MOV.VRO) that records stream data, inaddition to that file, so as to facilitate search and/or edit of streamdata.

[0487] F) A data structure which uses the values of time stamps recordedin the STREAM.VRO file or RTR_MOV.VRO file to identify/designateindividual transport packets/application packets in the management file(STREAM.IFO or RTR.IFO) that manages stream data (see FIG. 8(b) to (d)).

[0488] G) A data structure which forms a unit named a stream block (or adata unit called stream object unit SOBU) by combining a plurality ofsectors on the management file (STREAM.IFO or RTR.IFO), and providestime map information which has time information in units of streamblocks (SOBUS) to the management file, so as to facilitate time search(see FIG. 8(a) to (d)).

[0489] Note that the data sizes of at least the first and last streamblocks (SOBUs) in a stream object may be recorded in the time mapinformation in the management file (STREAM.IFO or RTR.IFO) (see FIG.3(i)).

[0490] H) A data structure that manages the value of the first timestamp in each stream block (SOBU) (except for a time stamp recordedcontinuously from the previous stream block) as the start time of eachstream block (SOBU) in the management file (STREAM.IFO or RTR.IFO) (seeFIG. 8(a) to (d)).

[0491] More specifically, the value of the first time stamp (e.g., TMS 1a in FIG. 8(b)) in each stream block (SOBU) is recorded in the time mapinformation in the management file.

[0492] A stream data recording method according to the present inventionuses an information storage medium which can record information in unitsof first recording units (sectors or stream packs), and records streamdata segmented into second recording units (transportpackets/application packets).

[0493] In a first recording area (stream recording area 222 in FIG.3(d)) that records stream data in units of second recording units(transport packets/application packets), packet header (or pack header)information assigned to each first recording unit (sector/stream pack),time stamp information having time information that pertains to streamdata of the second recording unit (transport packet/application packet),and stream data in units of second recording units (transportpackets/application packets) are recorded.

[0494] When the division (or cutting portion) of the time stampinformation or that of stream data recorded in units of second recordingunits (transport packets/application packets) is different from theboundary position of a first recording unit (sector/stream pack), thetime stamp information or stream data recorded in units of secondrecording units (transport packets/application packets) is recordedacross a plurality of first recording units (sectors/stream packs) (seeformer half 346 of transport packet b of program 2 in FIG. 5(e), andFIG. 5(h) to (j)).

[0495] In the stream data which is recorded finally on the informationstorage medium, when the end position of a second recording unit(transport packet/application packet) is different from the boundaryposition of a first recording unit (sector/stream pack), predetermineddata (e.g., all “1” bits or all “0” bits) is recorded as a padding area(21 in FIG. 1(k) or FIG. 6(h)) in an area after the end position of thefinally recorded first recording unit (sector/stream pack) or secondrecording unit (transport packet/application packet) (see FIG. 6(i) and(j)).

[0496] A second recording area (STREAM.IFO or RTR.IFO) that storesmanagement information pertaining to recorded data is recorded in thefirst recording area (stream recording area 222) (see FIG. 3(d) and(e)).

[0497] A third recording unit (stream block/SOBU) is formed bycollecting a plurality of first recording units (sectors/stream packs)with respect to a third recording area (stream file information) thatrecords time information which pertains to the first recording area(stream recording area 222) (see FIG. 6(b) to (e) and FIG. 8(a) and(b)).

[0498] The difference value between pieces of time stamp informationallocated at the head positions of the third recording units (streamblocks/SOBUs) with respect to stream data recorded in the firstrecording area (stream recording area 222) is recorded as time mapinformation (see FIG. 1(i) to (m) and FIG. 8(a) to (d)).

[0499] Also, an information storage medium having a data structure inwhich stream data are recorded by the aforementioned method is acharacteristic feature of the present invention.

[0500] Furthermore, as a method that allows partial erase in units oftransport packets in consideration of the I-picture start position, thefollowing method is used.

[0501] I) A stream object is newly segmented before and after thepartial erase position.

[0502] J) Information of stream file information that describesinformation which pertains to a STREAM.VRO file or RTR_MOV.VRO file thatrecords stream data, and playback unit information (cell information)used upon playback of stream data are stored in a management file(STREAM.IFO or RTR.IFO).

[0503] K) A partial erase process is done in units of ors for theSTREAM.VRO file or RTR_MOV.VRO file that records stream data.

[0504] L) A stream object is segmented on the management file(STREAM.IFO or RTR.IFO) in accordance with the I-picture start position.

[0505] More specifically, stream file information (SOBI_GI•251 in FIG.7(d)) stores stream object start time information (SOB_S_APAT 542 inFIG. 7(c)), and stream object end time information (SOB_E_APAT 543 inFIG. 7(c)). After partial erase, the value of a time stamp (1 a in FIG.7) corresponding to a transport packet (1 a in FIG. 7) that records theI-picture start position is changed (or additionally written) to thevalue of the stream object start time (SOB_S_APAT 542), and the value ofa time stamp (TMS 298 g in FIG. 7) corresponding to a transport packet(TP 298 g in FIG. 7) that precedes a transport packet which records theI-picture start position immediately after stream data including thepartial erase boundary position is changed (or additionally written) tothe value of the stream object end time (SOB_E_APAT 543).

[0506] M) On the management file (STREAM.IFO or RTR.IFO), the start/endpositions in cell information are set in correspondence with transportpackets which are designated to undergo partial erase.

[0507] More specifically, a partial erase range is designated in unitsof transport packets. The value of a time stamp (TMS 97 c in FIG. 9(j))corresponding to a start transport packet of those which fall outsidethe designated range is set as the corresponding cell start time(SC_S_APAT 283 in FIG. 9(j)) of a new original cell, and the value of atime stamp (TMS 224 k in FIG. 9(j)) corresponding to the last transportpacket is set as the corresponding cell end time (SC_E_APAT 284 in FIG.9(l)), thus changing (additionally writing) the contents of themanagement file (STREAM.IFO or RTR.IFO) accordingly.

[0508] An information medium to which the aforementioned partial erasemethod can be applied is a medium that allows information recording inunits of first recording units (sectors). This medium has a firstrecording area (STREAM.VRO or RTR_MOV.VRO) that records stream data, anda second recording area (STREAM.IFO or RTR.IFO) that records managementinformation which pertains to data recorded in the first recording area.In the first recording area (STREAM.VRO or RTR_MOV.VRO), packet headerinformation assigned to each first recording unit (sector), time stampinformation having time information that pertains to stream data of thesecond recording unit (transport packet), and stream data in units ofsecond recording units (transport packets) are packed and recorded. Athird recording unit (stream block) is formed by collecting a pluralityof first recording units (sectors). A fourth recording unit is formed bya plurality of third recording units (stream blocks) to indicate a largeset of stream data. In the second recording area (STREAM.IFO orRTR.IFO), time information (time map information) for each thirdrecording unit (stream block), and pieces of data size information ofthe third recording units (stream blocks) at the start and end positionsof the fourth recording unit (stream object) are recorded.

[0509] Stream data recorded in the first recording unit (STREAM.VRO orRTR_MOV.VRO) can be partially erased in units of first recording units(sectors). After partial erase, a fourth recording unit (stream object)having a new size is formed, and at least one of the data size and timeinformation of the third recording units (stream blocks) at the startand end positions in the fourth recording unit (stream object) havingthe new size is rewritten or newly recorded in the second recording area(STREAM.IFO or RTR.IFO).

[0510] The advantageous effects obtained upon practicing the presentinvention are summarized as follows.

[0511] 1. Since time information for each transport packet is recorded,as time stamp information, on the information storage medium togetherwith the transport packet,

[0512] a) the transfer timing of each transport packet to the STB unitcan be detected in correspondence with the time stamp value.

[0513] b) Since each transport packet can be transferred to the decoderat the timing corresponding to the time stamp value, decoding andimage-displaying can be stably done without any failure even if nobuffer is available on the decoder side.

[0514] c) Since individual transport packets can be identified anddiscriminated using the time stamp value, the arrival position uponaccess and/or the edit range can be easily designated.

[0515] 2. Time stamps and transport packets are sequentially packed andrecorded in the remaining portion of a sector after a packet header isexcluded. When the division (or cutting portion) of a time stamp or thatof stream data recorded in units of transport packets is different fromthe boundary position of a sector, either the time stamp or transportpacket is recorded to a position being across to the neighboring sector,and a padding area is set in only a sector at the video recording endposition (or, the last position of a stream object).

[0516] For this reason, stream data can be efficiently recorded on theinformation storage medium. As a result, stream data divided in units oftransport packets can be recorded without decreasing the actual capacityof the information storage medium.

[0517] 3. Time stamps and transport packets are sequentially packed andrecorded in the remaining portion of a sector after a packet header isexcluded. When the division (or cutting portion) of a time stamp or thatof stream data recorded in units of transport packets is different fromthe boundary position of a sector, either the time stamp or transportpacket is recorded to a position being across to the neighboring sector,and a padding area is set in only a sector at the video recording endposition (last position of a stream object).

[0518] Since contents of a packet can be recorded across adjacentsectors, a large packet having a size larger than the sector size (2,048bytes) can be recorded.

[0519] 4. According to an embodiment of the present invention, a timestamp is not always located immediately after a packet header in eachsector. Hence, as a method of extracting time information in units ofstream blocks, the embodiment of the present invention may use the valueof the first time stamp in each stream block (except for a time stamprecorded to extend from the previous stream block) as the start time ofthe stream block.

[0520] By so doing, time map information in the management file(STREAM.IFO or RTR.IFO) can be generated, and a prescribed transportpacket can be easily accessed using this time map information.

[0521] 5. When stream data in the STREAM.VRO or RTR_MOV.VRO file areallowed to be partially erased in units of sectors, the STREAM.VRO orRTR_MOV.VRO file can be partially released in units of minimum recordingunits (or, in units of sectors) with respect to an information storagemedium such as a DVD-RAM or the like. As a result, sectors released fromthe STREAM.VRO or RTR_MOV.VRO file can be effectively used to, e.g.,record computer data later.

[0522] Assume a case wherein partial erase is allowed only in units ofstream blocks (SOBUs) as partial erase units different from theabove-mentioned case (to partially release the STREAM.VRO or RTR_MOV.VROfile). Under this assumption, even when the user designates partialerase within a range as small as the sector size, part of the STREAM.VROor RTR_MOV.VRO file cannot be practically released due to too narrow apartial erase range. As a result, the small partial erase rangedesignated by the user cannot be used to record other data, and wastefulareas where information cannot be recorded may increase on theinformation storage medium in practice. However, the present inventiondoes not exclude use of partial erase in units of SOBUs.

[0523] 6. A management file (STREAM.IFO or RTR.IFO) that manages streamdata in a file (STREAM.VRO or RTR_MOV.VRO) for recording stream data isprovided on the information storage medium, in addition to that file,and cell information which records information that pertains to a cellindicating a playback unit upon playback of the stream data is recordedin the management file.

[0524] By providing start/end position information associated with thatcell as time information corresponding to a time stamp, a transportpacket represented by the time stamp value can be designated.

[0525] When the start/end position information of the cell is describedusing time information, a playback range after partial erase can beflexibly designated in units of transport packets.

[0526] 7. A management file (STREAM.IFO or RTR.IFO) that manages streamdata in a file (STREAM.VRO or RTR_MOV.VRO) for recording stream data isprovided on the information storage medium, in addition to that file,and stream object start time and stream object end time information arestored in stream file information present in that management file.

[0527] After partial erase, the time stamp value corresponding to atransport packet that records the I-picture start position is re-set tothe value of the stream object start time. Or, after partial erase, thetime stamp value corresponding to a transport packet that precedes atransport packet which records the I-picture start position locatedimmediately after stream data including the partial erase boundaryposition is re-set to the value of the stream object end time.

[0528] By so doing, it is possible to perform partial erase of streamdata (or to perform splitting/segmenting the stream data) to have theI-picture start position as the boundary position.

[0529] As a result,

[0530] a) since the decoder can always start decoding from the I-picturestart position, display can start from an arbitrary position in units offrames; and

[0531] b) since the I-picture position can always be detected frominformation of the management file (STREAM.IFO or RTR.IFO), and streamdata are split or segmented to have I-picture start positions asboundaries, when a plurality of different stream objects aresuccessively played back, video playback can be seamlessly andcontinuously made without disturbing images at the division (or changepoint at cutting portion) of stream objects.

[0532] 8. When a flag indicating the I-picture position is provided toeach of isochronous packet headers 343 and 344, STB unit 416 can informoptical disc device 415 of I-picture position information, in real time,simultaneously with transfer of stream data (transport packets).

[0533] As a result, I-picture position information can be easilyrecorded in the stream data recording file (STREAM.VRO or RTR_MOV.VRO)in real time, and the I-picture position information can also be easilyrecorded in the management file (STREAM.IFO or RTR.IFO).

[0534] Additional advantages and modifications will readily occur tothose skilled in the art. Therefore, the invention in its broaderaspects is not limited to the specific details and representativeembodiments shown and described herein. Accordingly, variousmodifications may be made without departing from the spirit or scope ofthe general inventive concept as defined by the appended claims andtheir equivalents.

What is claimed is:
 1. A method of recording information on aninformation medium which has a data area for recording stream data usingstream packets each of which includes an application packet areacontaining one or more application packets with time stamps, and amanagement area for recording management information that pertains tothe stream data, said method comprising: distributing the stream data tothe application packet areas in the stream packets so that thedistributed stream data are recorded in the application packet areas,wherein information recording is performed such that a start portion ofthe application packet area included in a first one of the streampackets of the stream data matches a first byte of the time stampappended to a first one of the application packets in the applicationpacket area.
 2. A method of recording information on an informationmedium which has a data area for recording stream data using streampacks each of which includes an application packet area having one ormore application packets with time stamps, and a management area forrecording management information that pertains to the stream data, saidmethod comprising: distributing the stream data to the applicationpacket areas in the stream packs so that the distributed stream data arerecorded in the application packet areas; and when a blank portion ispresent at an end of the application packet area, providing a stuffingarea formed of a predetermined number of bytes in the blank portion. 3.A method of recording information on an information medium which has adata area for recording stream data using stream packs each of whichincludes an application packet area having one or more applicationpackets with time stamps, and a management area for recording managementinformation that pertains to the stream data, said method comprising:distributing the stream data to the application packet areas in thestream packs, and recording the distributed stream data in theapplication packet areas; and as a result of recording the distributedstream data, if a blank portion of one or more of the stream packsappears between an end of a last one of the stream packs that actuallycontains the stream data, and an end of the data area for recording thestream data, then recording a stuffing packet in the blank portion. 4.An information recording method using an information medium which has adata area for recording stream data using data packets and data unitseach being larger than the data packet, and a management area forrecording management information that pertains to the stream data, saidmethod comprising: constituting the stream data by a plurality of thedata units; constituting each of the data units by one or more datapackets each of which records predetermined time stamp information; andrecording, in the management area, at least a time difference valuecorresponding to a difference between a first time stamp recorded in afirst data unit and a second time stamp recorded in a second data unit,said first and second data units being included in a plurality of saiddata units.
 5. A method according to claim 4, wherein the timedifference value is determined by rounding to a predetermined number ofeffective digits a difference between a time information valuecorresponding to the second time stamp and a time information valuecorresponding to the first time stamp.
 6. A method according to claim 4,wherein a value of a first time stamp recorded in a first one of thedata packets located in the data unit is used to compute the timedifference value.
 7. A method according to claim 4, wherein a time stamprecorded in the data packet at an end of a last one of the data unitsincluded in the stream data indicates an arrival time of a last one ofthe data packets in the last data unit, and the arrival time of the lastdata packet is used to compute the time difference value.
 8. Aninformation recording method using an information medium which has adata area for recording stream data using data packets and data unitseach being larger than the data packet, and a management area forrecording management information that pertains to the stream data, saidmethod comprising: recording information of one or more cells in thestream data; recording, in the management area, program chaininformation that describes a set of one or more of the cells; andrecording, in the management area, information of an entry point whichcan be used as a marker of a skip position upon partially skippingrecorded contents of the stream data in playback.
 9. A method accordingto claim 8, wherein the management area includes stream object generalinformation which includes at least one of recording time information ofthe stream data, a data packet arrival time of a start portion of thestream data, and a data packet arrival time of an end portion of thestream data.
 10. A data structure which has a data area for recordingstream data using predetermined data recording units, and a managementarea for recording management information that pertains to the streamdata, wherein a plurality of stream packs, each of which contains one ormore of the data recording units with time stamps, are provided, and thestream data are distributed to these stream packs, each of the streampacks contains a pack header and a stream packet, and a start portion ofan application packet area included in a first one of the stream packetsof the stream data matches a start byte of the time stamp appended to afirst one of the data recording units in the application packet area.11. A data structure according to claim 10, wherein the stream packetincludes a stuffing byte of a variable length including zero bytelength, and the application packet area including one or more of thedata recording units with time stamps.
 12. A data structure which has adata area for recording stream data using data packets and data unitseach being larger than the data packet, and a management area forrecording management information that pertains to the stream data,wherein the stream data are distributed to application packet areas eachincluding one or more of the data packets, and when a blank portion ispresent at an end of the application packet area, a stuffing area formedof a predetermined number of bytes is provided in the blank portion. 13.A data structure according to claim 12, wherein if a blank portion ofone or more stream packs appears between an end of a last one of thestream packs that actually contains the stream data, and an end of thedata area for recording the stream data, then a stuffing packet isrecorded as padding data in the blank portion.
 14. A data structurewhich has a data area for recording stream data using data packets anddata units each being larger than the data packet, and a management areafor recording management information that pertains to the stream data,wherein the stream data includes a plurality of the data units, each ofthe data unit includes one or more of the data packets each recordingtime stamp information, and a time difference value corresponding to adifference between a first time stamp recorded in a first data unit anda second time stamp recorded in a second data is recorded in themanagement area, said first and second data units being included in saiddata units.
 15. A data structure according to claim 14, wherein the timedifference value is determined by rounding to a predetermined number ofeffective digits a difference between a time information valuecorresponding to the second time stamp and a time information valuecorresponding to the first time stamp.
 16. A data structure according toclaim 14, wherein a value of a first time stamp recorded in a first oneof the data packets located in the data unit is used to compute the timedifference value.
 17. A data structure according to claim 14, wherein atime stamp recorded in the data packet at an end of a last one of thedata units included in the stream data indicates an arrival time of alast one of the data packets in the last data unit, and the arrival timeof the last data packet is used to compute the time difference value.18. A data structure which has a data area for recording stream datausing a data packet and a data unit larger than the data packet, and amanagement area for recording management information that pertains tothe stream data, wherein one or more pieces of cell information arerecorded in the stream data, information of a program chain thatdescribes a set of one or more cells is recorded in the management area,and the management information includes information of an entry pointwhich can be used as a marker of a skip position upon partially skippingrecorded contents of the stream data in playback.
 19. A data structureaccording to claim 18, wherein the management area includes streamobject general information which includes at least one of recording timeinformation of the stream data, a data packet arrival time of a startportion of the stream data, and a data packet arrival time of an endportion of the stream data.